[
Lists Home |
Date Index |
Thread Index
]
W. E. Perry wrote:
> Jonathan Borden wrote:
>
> > It is not totally clear to me that the GI and DOCTYPE definition need
define
> > the same 'type'.
>
> No indeed. Given the differences in the (multiple) roles of each, it
requires
> tortured construction to say that what they define is in any sense at all
the
> 'same'. Actually, the root element GI and the DOCTYPE name do not 'define'
> anything. Each is a lexical anchor or identifier to which content models,
> schemata, and processing strategies--which go further in attempting to
define
> something--might be attached, which was my particular point.
Exactly.
>
> > That is to say, the GI of the root element, particularly when the
element is
> > namespace qualified, points to the namespace as 'half' of the type and
the
> > 'local name' which is qualified by the namespace, as the other 'half'.
>
> Taking 'namespace' here in the purely lexical sense employed by
"Namespaces in
> XML", this is of course true, but it means no more than that, to a
> namespace-aware processor, the lexical anchor provided by the root element
GI is
> simply one component of a larger lexical anchor.
Yes, but being at the root of the XPath, or the element name of the first
SAX event that gets fired, the root element is the root of the larger
lexical anchor.
>
> > I posed the hypothetical question in order to help sort out this issue
> > ("Strategies for a lowly XML document"):
> > http://lists.xml.org/archives/xml-dev/200201/msg01355.html
>
> You propose one strategy, based on a PI, which may be useful. It is
certainly
> not harmful, as anything which provides more information about an instance
> document to a potential processor of that document might well be helpful.
As
> always, however, 'intent' expressed by a document creator is not binding
upon
> potential processors of that document, who are free to ignore expressions
of
> that intent, as PIs or otherwise.
That is the thrust of my argument, that while 'document type' may add more
information, it doesn't solve the problem that has been posed.
>
> > Gavin feels strongly that the instance ought not dictate the processing:
> > http://lists.xml.org/archives/xml-dev/200201/msg01408.html
>
> He is right.
>
> > So perhaps the conclusion is that 'document type' is not a useful way to
> > direct processing.
>
> But often it is, given the particular purpose of that processing and the
> resources available to it which might not be known to the document
creator.
Yes but the document creator has to insert the PI or root attribute, so
ultimately the document types has the same problems as root element GI +
context (in both cases you are looking at the document and trying to figure
out what to do with it).
>
> > When the author of a document has a specific and single intended
'semantics'
> > to be associated with the instance, the markup ought be highly
constrained and
> > reflex this intent. In such cases the root element name does need to
know, or
> > have the means to find out about, all its offspring. It is in such cases
where
> > XML namespace qualification is particularly helpful, because the
> > root element namespace name/URI is a means of obtaining information
about the
> > namespace and hence the intended semantics of the root element.
>
> OK, but I argue that this is not the general case. This is an instance of
> specific agreement between document creator and document processor utterly
> outside of the content of the instance document. The namespace mechanism
you
> describe here is simply the lexical signal to both the document creator
and
> document processor that this instance document is subject to their a
priori
> agreement.
>
Just as the usefulness of whether a document validates against a DTD
provided by the document creator. Both DOCTYPE and namespace are lexical
signals subject to external agreements. It is precisely when the creator and
user of a document _agree_ that the semantics of the document are to be
provided by the creator, that the namespace or PubId or SysId are useful
ways of obtaining information about the intended semantics, just as they
might be used for the intended syntax.
Jonathan
|
