>I am still not sure that I like the idea of so many files; I will have to
>think about that for a while. I do agree that we need to have a defined
>unit (I'll use node) that, in this case, is the unit of transport and
>display. I reference to Dan's concerns for context, it is at the
>node level that we must make sure that the context variables are
>either well defined or non-existent.
>However, I am not sure that the physical storage model has to be the
>same as the node model. There could be an assumption that the server
>will do something to break apart node sets and deliver them one
>at a time.
This view of separating the physical storage from the node model
is also supported by the experience of using conversion packages.
One reason they are attractive is that source documents are created and
maintained as single entities containing enough information for an
automated process to extract the nodes and link them in a sensible
and uniform way.
The same could be done for large HTML documents if there were
appropriate tags to specify the node structure from within
one or more physical files.
Such tags would be useful for HTML editors and conversion packages
because they could all use the same back-end filter (or rely on a gateway,
or a server, or a client) to decide how to create (or serve or display)
-- Nikos Drakos Computer Based Learning Unit firstname.lastname@example.org University of Leeds http://cbl.leeds.ac.uk/nikos/personal.html