Re: Radical cure for BOS confusion
>At 4:26 PM 1/9/97, papresco wrote:
>>At 01:05 PM 1/9/97 -0500, David G. Durand wrote:
>>> If you want to _analyse_ link relationships, then I think a requirement
>>>to fetch the DTD is reasonable.
>>Does this mean that the documents to be analyzed must adhere to a DTD? Note
>>that there is a large commercial market (and robust freeware "market") for
>>spiders, link checkers, web site downloaders, etc. DTD-less XML documents
>>should not be less workable in this regard than HTML documents.
>Ss far as I can tell, all architectural form proposals will require adding
>attributes to elements. If we don't want to put them on every single
>element we will have to put them in the DTD. If we let the first occurrence
>set a default, we have introduced a serial dependency of the sort we
>intentionally avoided in the definition of the XML language.
Are there not serial dependencies in XML already concerning, say, the
XML PI's relative to the constructs they talk about? Are serial dependencies
a "good thing" in the sense that they will allow XML browsers to do
incremental rendering/processing etc.
For elements though, "first-ness" is kinda fluid. XML->XML transformations
for instance. It could be quite easy to forget that prior to serialisation
after a tree transformation, an XML processing app. will have to re-establish
"first-ness" and add the necessary attribute decls.
It would sure be nice if XML processors could locate all the required
AF stuff in one easily locatable spot. As Eliot said recently, ot can be
done with the declaration subset but that requires extra DTD declaration
At the risk of sounding like a broken record. every new construct added
to XML that is required for well-formed XML processing will make uptake
in the s/w dev. community that much more difficult. Playing devils advocate
for a moment a developer mentality might say:-
"Look, I have written the code to handle PI's. If you add extra semantic
stuff to XML, allow it do be done with PI's. My code reads/writes PI's already."
Sean Mc Grath