>Meta-comment: we're suddenly getting a spate of comments that point to
>little inconsistencies or ambiguities in the spec, reflecting the fact that
>it is written very informally. I think the problems are particularly acute
>when the spec tries to talk about the actions of "XML processors" or
>"applications" because these notions are very fuzzy.
Several of us on the Working Group complained about this at the time. This
was always a problem with the SGML spec and was, in my opinion, made worse
in XML by reference to "processors" rather than "parsers". The problem is
that XML (like SGML) only defines a syntax, not an abstraction constructed
from that syntax. In SGML, we got part of the way there by defining the
SGML property set that defines the normative form for parsed SGML
documents, but we *didn't* formally define the "grove construction process"
by which you go from the syntax to the abstraction--that was mostly
implicit in the property set definition and explicit in a few places, but
ultimately underspecified (but we did have a reference implementation in
James Clark's Jade processor).
For XML, we need to have the same thing: a normative definition of the
abtraction you get by parsing an XML document and a normative definition of
the algorithm for going from the syntax to the abstraction (ideally the
abstraction should be consistent with SGML's). That is, an abstract data
model and construction algorithm. Note that the DOM is not this as it is
an implementation-specific *object model* for a particular class of XML
processor, not an abstract *data model* divorced from any specific
implementation or type of processor.
Until this is done, there will always be inconsistencies and ambiguities in
the XML specification because there is no way to formally define what an
"XML processor" is.
Cheers,
E.
-- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address>