Re: XML processor profiles: XML Base processing

* Henry S. Thompson wrote:
>>   In http://www.w3.org/TR/2010/WD-xml-proc-profiles-20100518/ section 3
>> there is a requirement "Maintenance of the base URI property of each
>> element in conformance with [XML Base]". This requirement needs to be
>> elaborated in at least two ways. Firstly, it needs to be identified
>> whose property the "base URI" property is; secondly, it is difficult to
>> see what effect the requirement has beyond affecting XInclude processing
>> for which the requirement is already implied.
>
>We've tried to address your first request in a draft of next WD [1], [2].

The XML Base specification defines what the base URI of an element is,
it does not mention there being a `property`. There are specifications
where elements have a `base URI property`. So when the draft uses the
term, it is not clear what it means. Consider that the XML Base speci-
fication mentions that the Infoset's [Base URI] property can become out
of sync with the xml:base attributes (whatever that means).

>Wrt your second request, the reason point (2) of the minimum and basic
>profiles references XML Base is in keeping with the overall goal of
>this spec: to provide a single point of reference for other specs. to
>use to get a carefully defined statement of what their 'front end'
>must do.  So, we're referencing XML Base and requiring conformance so
>that specs which reference us don't have to.  Do you think this
>actually needs to be spelled out?  It seemed to us that we got what we
>wanted by the normative reference to XML Base. . .

It is common practise for specifications to require that relative re-
ferences are to be resolved against a base reference that is different
to what the XML Base specification says the base reference is. Take as
examples the `data` attribute of `object` elements in HTML 4 documents
(which is relative to the `codebase` attribute), the `rel` attribute on
the `atom:link´ element in Atom documents (which is relative to a pre-
defined reference), or the `href` attribute of the `xsl:result-document`
element in XSLT 2.0 documents (which is relative to an implementation-
defined reference).

So if your draft said "Elements have an associated base URI property
whose value is whatever the XML Base specification says the base URI
of the element is" and a specification uses your draft via "Conforming
implementations must construct input data models from XML documents as
required by the basic XML processor profile" and then defines how to
resolve relative references by referring to this "base URI property",
then nothing has been gained over doing so by referring to the XML Base
specification directly. In fact, it would be more confusing.

Right now you would need the reference anyway because your draft only
discusses the base URI of elements, not that of attribute values, for
example, if you have any references in attribute values; or if you have
one as text node, or in a processing instruction, and so on. And then
there are cases like those above.

Put differently, while "Conforming implementations must construct input
data models from XML documents as required by the basic XML processor
profile" would give you a document where external declarations have been
read, where includes have been expanded, and where xml:id attributes are
of type "ID", "Maintenance of the base URI property" has no effect at
all, unless there are additional references to your specification that
do give that requirement meaning -- while the purpose of the draft is to
avoid that, as I understand it.

My guess is the idea behind XML Base was at some point that you can just
say "Relative references: check XML Base on those" and your draft tries
to be a proxy for that; that would work if everyone was using XML Base
and always stick to the rules in XML Base, but reality is sufficiently
different that this kind of implicit definition is not clear enough. So
I would recommend to remove XML Base from the draft.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 1 June 2010 19:08:50 UTC