Re: More proposals -- and some critical implementation issues

At 6:09 AM 1/1/97, Martin Bryan wrote:
>At 13:12 31/12/96 -0500, David G. Durand wrote:
>>Since we have gone to great lengths to enable an Explorer or
>>Navigator-equivalent to avoid processing DTDs, we can't afford to require
>>them for linking behavior to work. This is only my opinion, but it's sure a
>>hard case to make as part of a sales pitch. Same for the attribute values
>>-- the redundancy will be noticable, and make XML look foolish, when it is
>>in fact merely being punctilious.
>>
>Why will the redundancy be noticeable? How many users look at the code
>coming into their Netscape browser? The redundancy will only be present when
>the file is being transmitted to a dumb browser that cannot handle the DTD.
>If it can handle the DTD there will be no redundancy as the attributes won't
>need to be added before transmission.
    I expect that authors will see the redundancy: most static documents
are sent verbatim by servers -- this is mostly an efficiency issue, but it
does not seem to be changing. I doubt that most servers will add attributes
to document instances when the DTD is not being processed. I certainly
would not want to end up making such server processing a de-facto
requirement for linking to work. And, there is currently no way that we can
tell whether an application has (or intends to fetch) the DTD for a
document unless we add new DTD intention parameters to HTTP. In other
words, if there is no DTD, we will have no default attribute values. We
decided that this was OK for graphical rendering because we are assuming
that the stylesheet can work without that explicit information. I propose
that we follow the same strategy for linking. In both cases, certain errors
can occur, especially if the attribute definitions change and the
stylesheet does not.

   In both cases we have a mandatorily interpreted set of _declarative_
information (DTD or link architecture specification). This means that
non-rendering applications do not have to try to deduce the functions of
stylesheet code, but can read the DTD. It also offers authors the option to
require the DTD for correct operation of the stylesheet (by simply not
assuming default values for undefined attributes).  The market and users
will decide if and when these separate strategies are most useful.

>Browsers would only need to be able to identify a few extra attributes,
>those identifying XML link AFs. They will need to be able to recognize these
>in any case to process XML links. Nobody is suggesting, surely, that
>Netscape and Explorer should be able to handle multi-headed XML links
>without modification. If we are constrained by what these browsers can do at
>present then we might as well give up now.

No, but we can make reasonable assumptions about what certain implementors
are likely to do... If Netscape were to immediately see the value of
rigorous DTDs I would fall down dead from shock. Separate stylesheets =>
two HTTP hits already. This will be a tough sell... The chance people would
accept 3 hits per document seems very low to me.

   We may yet have to bite the bullet and allow stylesheets within
documents: which is a very bad idea, I think. But I don't see how we can
require DTDs for linking, and claim to have eliminated them from XML -- at
least in the web context, linking is a hard requirement.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 1 January 1997 22:28:29 UTC