xml-dev - Re: SDD bogus

[David Megginson <ak117@freenet.carleton.ca>]

Paul Prescod writes:
 > David Megginson wrote:
 > > 
 > > In the end, as one might have predicted, there is an impressive range
 > > of free XML processors available in several different programming
 > > languages: someone writing an RDF tool does not need to worry about
 > > the character and entity level of XML at all, and can work with XML
 > > easily through a more abstract interface such as the DOM or SAX.
 > 
 > That's a dangerous heresy, though one that I've promoted myself. If we
 > presume that programmers are going to work through parsers, then why
 > couldn't we leave GI's out of end tags and make XML substantially less
 > verbose (qualitatively at least)? 

It's a matter of finding the right balance: XML must be simple enough
to parse that there is a healthy competition among parser writers (and
thus, a better quality and larger choice of tools for application
writers), but simple enough to write that authors (including
developers of tools that generate XML) are willing to learn and use
it.  SGML, with its bizarre tag-omission rules, delimiter-in-context
recognition, shortrefs, etc., gave too much away to the authors, and
as a result, there were very few good SGML parsers implemented (and
never a one in Java, although many of us tried).

 > > So, we should let the authors decide -- if an author creates a
 > > document referencing external entities (including an external DTD
 > > subset), then the XML parser should handle them; if the author does
 > > not want to use external entities, then she can simply avoid
 > > referencing any.
 > 
 > Although I agree with Tim that this is a separate issue, I agree with you
 > that external entities should always be processed. It seems strange to me
 > to put responsibility for managing performance in the hands of the parser.
 > The parser writer has no information about the performance characteristics
 > of the entity vs. the importance of the data. Ignoring content should not
 > be the parser's perogative.

I'd take one step towards Tim's side, and allow the _application_ to
specify whether (and which) external entities may be included, since
they may have special knowledge that the parser lacks; you are quite
right, though, that it should not be up to the parser, and that all
parsers should be able to include external entities.  In XML 1.1, I'd
like to see one of those "at user discretion" clauses here.

 > Consider Tim's example:
 > 
 > > Netscape today
 > > announced that &NSA;. In
 > > response, Microsoft
 > > issued the following
 > > statement: &MSA;.
 > 
 > As an author, I would be pretty damn pissed off if a browser
 > presented the document that way, even if it uses nice icons for the
 > entities. What does the document mean with half of its text
 > missing? If I've used external entities in that way, then I have
 > probably decided to do it for a good reason. If I wanted a text
 > inclusion that could be downloaded after a mouseclick, that sounds
 > like a special behaviour that could be accomplished through XLink.

Absolutely correct: an entity is a fundamental chunk of a document,
not a link (web heads can think of it somelink sort-of like a
client-side include).  I'm sorry to see that this kind of
misunderstanding arose as recently as last fall, especially since work
was already well underway on XLink (aka XLL aka XML-Link), so (as you
mention) people could see what kind of mechanisms would be available
for linking to embedded information.

In any case, couldn't a browser render around the entity references,
then adjust the rendition as the entities were resolved, as HTML
browsers generally do with images?


All the best,


David

-- 
David Megginson                 ak117@freenet.carleton.ca
Microstar Software Ltd.         dmeggins@microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)