Argh...Entities

[Paul Prescod]

Noah has given me some feedback on the schema-comments list that I would
like to forward (with permission) and respond to.

Noah_Mendelsohn/CAM/Lotus at lotus.com wrote:
> 
> The schemas WG has given very serious consideration to the view that
> validity constraints should be somehow separated from anything in the
> schema that affects content.  Entities do affect content and could be
> eliminated or perhaps "put in a box" as you suggest.

[by put in a box he means to make a separate specification that would
handle them]

> The more difficult case, I think, is default values for attributes.  These
> too affect content (and in the case of default values for namespace
> attributes can affect the deeper meaning of the document structure.)
> Anyway, we've heard strong opinions expressed that (1) default values for
> attributes are an important feature of any replacement for DTDs and (2)
> that it would be very cumbersome to define the default values somewhere
> that is far removed from the declaration of the attribute itself.  The
> natural place to introduce a default does seem to be on the attribute
> declaration.

I agree, this does seem natural. Here are reasons it seems natural:

 a) people view the DTD document as documentation for the language

 b) DTD writers want to communicate to application writers that there is
some specific default that makes the most sense

 c) DTD writers want to be able to change their mind about the specific
default later.

What if we rethought the attribute default mechanism in terms of these
goals? Instead of having default attributes change the parse tree as seen
in a DOM 1.0 tool, (i.e. at the lowest infoset) we can have them attach
extra nodes to the infoset that the application gets by viewing the data
through the schema. The necessity of this infoset is a given: how else
will applications know their data types and so forth?

In other words, attribute defaulting is a service provided by the schema
engine to the application just like data type recognition and attribute
value type recognition. It would NOT be a service provided to or by the
parser (using the old fashioned definition of parser that did not include
the entire universe). Probably defaulting would occur after namespace
application (which wouldn't need it) but before (e.g.) XSL application
(which would).

If it makes it clearer, we can even stop referring to it as a default
value and instead refer to it as a "suggested value." And note that you
can build this as a SAX filter or DOM layer on top of XML 1.0 SAX or DOM.

Text entities cannot really be rethought this way because XML 1.0 requires
them to be resolved before anything else can proceed. Plus text entities
are probably just not a good idea anyhow: we should be glad to let them
die out.

> So, depending on how you feel about that analysis of attribute values,
> pandora's box is then open.  

I can see that the box is open but only a crack.

If we think of the levels as:

1. physical
2. logical
3. DTD/schema-augmented logical

Then default attributes can be considered to be at level 3. If we want to
push them back into the parser (I advise against it) then we could call
them level 2. But to influence level 1 from level 3 seems particularly
gruesome and not backwards compatible. If we do it the "wrong way" then
attribute defaulting is analogous to an ingrown toe-nail but text entity
insertion is more like an ingrown toe. (sorry!)

> The schema can afffect the contents of a
> standalone=no document.  Having, with regrets, crossed that bridge, does
> that change the net tradeoff on entities?  Maybe.   The standalone=no
> document is already potentially dependent on the schema for other reasons,
> I.e. attribute defaults.  Now the question is:  be a proper superset of
> DTD, including questionable features, or leave out entities?
> 
> Anyway, these are some of the issues we wrestled with.  You can see where
> we landed this time.  Thanks again for the feedback.
> 
> Noah

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Diplomatic term: "Regret"
Translation: To care, but not enough to condemn. ("We regret the loss of
             life in Sierra Leone. We have no intention to do anything 
             to stop it, mind you, but we regret that it happened.")
(Brills Content, Apr. 1999)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)