I think that serialisation is a part of an object system=2E We are dealing=20
with object systems that can be - potentially - viewed through multiple=20
functional lenses=2E To enable this we've decided upon a standard way to=20
serialise and instantiate instances - XML and domBuilders=2E
>When processing a document, the application should decide on
>the classes to be used depending on (a) the markup language
>of the document and (b) how the document is to be processed=2E
I agree=2E Although I dont think we should think of processing documents=2E=
We=20
should view it more generally as invoking operations on an object model=2E
>For serialization, the mapping should be specified in the
>document=2E
The elementNode would / should provide the XML serialisation, any further=20
serialisation formats are implemented in the functional mixins, as are the=20
application specific methods=2E The application will serialise the structur=
e=20
as and when it needs to=2E If I'm sending my object model to an XML aware=20
process then i'll use the elementNode serialiseXML method, if I'm sending i=
t=20
as the response to a request for a web page then I'll call the mixed-in=20
serialiseHTML method=2E
>> But we should be able to mix these=2E
A delegation model would support the dynamic inclusion and reconfiguration=
=20
of the functionality of a given instance=2E Thus providing multiple functio=
nal=20
mixins and multiple mixin configurations=2E
graham=2E
gdm@dpsl=2Eco=2Euk