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.
What parameters of a physical storage model are relevant to the web?
I think that this model should cater to the information providers as
much as possible and require that the server/browser developers
provide the bridge between their needs and the "surfer".
Anyway, some specific comments follow...
> Dave Raggett writes:
> For existing browsers, HTML nodes are standalone. I have been thinking about
> this for some time as is evident from the various drafts for HTML+. You can
> use the LINK element in the document head to define relationships between
> nodes, for instance: index, table of contents, glossary, etc. You can also
> define parent->child relationships and use these to imply LINK elements in
> child nodes. This is also applicable to hypertext paths. I have recently
> added the SRC attribute to LINK in a bid to allow authors to use images
> for links which are intended appear in a document specific toolbar.
I would like to see this src attribute (and shape?) available as a
"button" (I believe that hytime calls/used to call this an endterm)
to allow a graphics to be consistently associated with a link.
This assumes that the "A" element will be extended to include an IDREF to
a link element; I believe has been recommended before to help with
BTW...the version of the HTML+ dtd available via the web
(tp://184.108.40.206/pub/htmlplus.dtd.txt) does not have the src
Also, if there is to be some "significant" values for the rel attributes
then that attribute should be an enumerated list. If technology
prevents a list, then at least document the values within the
DTD. Otherwise, no two browsers will behave the same way and the
feature becomes useless for transportable documents.