XML Base Disposition of Comments (original) (raw)

2.1. Technical Errors and Clarifications

2.1.1. Why is XBase needed?

Source: Rick Jelliffe,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0046.html.

Rick proposes that the functionality of xml:base is already available in the form of XML entity references, <html:base>, and variables in XSLT transformations. Rick also is concerned by a lack of a Requirements document specifically for XML Base.

Resolution: members only) Declined. Rationale follows:

2.1.2. "XBase" abbreviation is confusing

Source: Steve Hodgkiss,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0051.html. Also see linking issues list [XB2] (members only).

The term "XBase" previously referred to dBase, FoxPro, Clipper, et. al. as in the "XBase World" or "XBase Community". Unique terminology would be welcomed.

Editors comments: Defining a shortcut XBase for XML Base is of dubious value. We're only defining a single attribute, which is called "xml:base", not "x:base". We don't have XSpace or XLang. There is such a thing as taking the XWhatever naming convention too far.

Resolution: (members only) Accepted. Lose the acronyn XBase.

2.1.4. Clarify use over HTTP

Source: John Tigue, email to editor.

How about some explicit references to how this works over HTTP. Specifically, Section 14.11 entitled, "Content-Base" of RFC 2068 (which I notice doesn't appear in RFC 2616)?

This would follow the model of the xml-stylesheet spec: http://www.w3.org/TR/xml-stylesheet/

Resolution: (members only) Declined. The more recent RFC 2616 states in Section 19.6.3 entitled "Changes from RFC 2068":

Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce it without a robust extension mechanism.

Thus we defer to their judgment on what was widely implemented and would benefit from clarification in our spec.

2.1.6. relative base URI reference defined circularly

Source: Dan Connolly,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0008.html.

Base is definition is circular, a relative base URI is resolved relative to the base URI.

Suggested replacement text: "The value of the xml:base attribute denotes a URI with respect to the [base URI] property of the *parent* of the element on which it appears, provided the parent element starts and ends in the same external entity; otherwise (e.g. if the xml:base attribute occurs on the root element of a document) it denotes a URI with respect to the base URI of the enclosing external entity." And add an example of relative base URIs.

Resolution: (members only) Accepted.

2.1.7. XBase is in conflict with RFC 2396

Source: MURATA Makoto,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0011.html. Also see linking issues list [XB9]. (members only)

At present, a default value for the xml:base is allowed to appear in an external DTD subset or external parameter entity. Then, that default value would control all XML document entities that reference to this external DTD subset or external parameter entity. This is a violation of RFC 2396.

Options from this and subsequent threads include:

  1. XML Base should prohibit default values for xml:base.
  2. XML Base should prohibit default values for xml:base in external DTDs.
  3. Add a note indicating that the base may be inherited from a different Mime entity.
  4. Do nothing - treat the use of an element type which defaults xml:base as sufficient indication within the document entity of the base URI.

Further investigation reported by Steve DeRose inRFC 2396 and BASE (member only), and reproduced here for convenience:

... I went and looked over 2396 in detail. For one thing, it says:

5.1.2. Base URI from the Encapsulating Entity

If no base URI is embedded, the base URI of a document is defined by the document's retrieval context. For a document that is enclosed within another entity (such as a message or another document), the retrieval context is that entity; thus, the default base URI of the document is the base URI of the entity in which the document is encapsulated.

Now with XML Base, there is no unique meaning to the phrase "the base URI of the entity in which the document is encapsulated" -- because there may be many. It seems to me that the most reasonable interpretation of this clause in the face of that fact would be "the base URI [at the encapsulation point in] the entity in which the document is encapsulated -- that is, when an entity is included in another and the enclosing doc has multiple bases at different places, choose the one that's in effect at the relevant point ...

But perhaps most telling, check this out from section 5.1.1:

Protocols that do not use the MIME message header syntax, but which do allow some form of tagged metainformation to be included within messages, may define their own syntax for defining the base URI as part of a message.

XML is, in itself, a protocol that does not use MIME, but which allows tagged metainformation. So it may define its own syntax for defining the base URI as part of its "messages". "message" is a MIME term, and this paragraph is talking about MIME -- but isn't the best interpretation of "message" in XML terms, "document"? In which case, this clause appears to permit exactly what we want.

I couldn't find the constraint that's supposed to be there, that the BASE must be defined in the same MIME object. I examined every instance of "base", "MIME", and even "must" in RFC2396.... Can anyone else find it? Or perhaps were people thinking of the 5.1.1 text just cited, which does not seem to have any clear conflict with what we want.

Resolution: (members only) However, in light of these concerns, and despite the doubts raised by Steve, we will attempt to mitigate the problem. It seems impractical to enforce restrictions on where xml:base attributes may be declared, as some processors cannot be expected to have this information, and enforcement (or even ignoring such attributes) cannot be reliably performed without changes to XML 1.0 parsers. We note that Namespaces faces a similar problem (defaulting something as intrinsic to a document as the namespace declarations is unwise), and we will add a note to XML Base phrased along the same lines as appear in the Namespace rec, warning users not to engage in such practice.

2.1.8. Deployment strategy unclear (2nd last call)

Source: Larry Masinter,http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Jun/0056.html (members only).

When you say "Relative URIs appearing in an XML document" you need to be completely clear about:

Exactly which "XML documents" it applies to, since it clearly does not apply to any context in which XML appears.

Exactly which "relative URI references" it applies to, within those documents, since even for documents that are in scope, it does not apply to all possible strings which use the relative URI reference syntax.

Resolution: (members only) Accept. Add the following wording to the start of Appendix C:

XML Base defines a mechanism for embedding base URI information within an XML document. It does not define a mechanism to recognize which content or attribute values might contain URIs. This is only known by the specifications or applications assigning semantics to the vocabulary.

It is the intention of XML Base that future specifications and revisions of XML vocabularies identify which parts of the XML document are considered to be URIs, and provide normative reference to this specification in order to ensure that relative URIs are treated consistently across XML documents.

2.2. Requests From Other Working Groups and Member Companies

2.2.1. I18N: scoped attribute support

Source: Martin J. D�rst,http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html (members only). Also see linking issues list [XB4]. (members only)

The XML Base spec defines an attribute xml:base that works in a nested/inherited way. This is similar to xml:lang. Support for such attributes in W3C technologies, e.g. in XSLT or XML Schemas, is currently scarce if not non-existent. The I18N WG/IG hopes that both groups can use their contacts to make the relevant W3C WGs aware of the need for such support.

Resolution: (members only) Remove the sentences noting the similarity to xml:space and xml:lang as it does not add any normative value. I also note here that XPath has some facility for scoped attributes - ancestor-or-self::*[@xml:lang][1]/@xml:lang identifies the xml:lang attribute currently in scope.

2.2.3. I18N: scoping into external entities

Source: Martin J. D�rst, Thread starting at http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Mar/0020.html (members only). Also see linking issues list [XB6]. (members only)

I18N asked us to clarify the difference between not extending into external entities and extending into external entities. After such an example was provided, Martin stated: "I think that things should work the other way from how they are specified now." In other words, xml:base SHOULD extend into external entities, one reason being that internal and external entities should be handled consistently.

  1. Provide for the extension of base into external entities.
  2. Define (if XML 1.0 allows us to) that the base URI of elements in an internal entity are set to the base URI of the document entity. Thus entities would always carry their base independently of their context.
  3. Note the discrepancy and warn users about it.

Resolution: (members only) Option 3, note the discrepancy and warn users of it. Changes to support the extension of xml:base into external entities are declined for the following reasons:

  1. Canonicalization already breaks things, so the existence of scenarios broken solely by this feature is dubious.
  2. The base would be context dependent when relative URIs are used, which would tend to be confusing and may cause unexpected behavior, e.g. broken links.
  3. See the concerns about the wisdom of this practice raised by the comment "XBase is in conflict with RFC 2396".
  4. Suggested behavior is inconsistent with the Infoset and the XPath Data Model.

Extending the scope into internal entities also is rejected, internal and external entities are used very differently by customers, and consistency here does not seem necessary. Infoset and possibly XPath would need to reflect this change - the costs are not justifiable.

2.2.4. Schema: xml:base information item handling

Source: C. M. Sperberg-McQueen,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0081.html.

XML Schema depends on the infoset to carry information about xml:base declarations. Schema suggests three possible resolutions:

  1. Make the xml:base available as a scoped information item similar to namespaces.
  2. Make the xml:base information available through convenient core properties on all relevant information items.
  3. Make the base URI information item mandatory (core) not optional (peripheral).

Resolution: (members only) Out of scope. This functionality has been moved to the Infoset. We believe they are adopting a solution along the lines of options 2 and 3.

2.2.5. DOM: impacts of xml:base on namespaces

Source: Lauren Wood,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0085.html.

XBase makes the current ambiguity about relative URIs in namespaces more acute. As such the DOM recommends:

  1. XBase should state clearly whether it should apply to namespace URIs or not.
  2. Don't consider XBase final until the interaction with namespaces is clarified.
  3. Clarify that making the relative URI absolute by using XBase still does not make it identical with an absolute namespace URI. Only the act of traversing a namespaceURI actually requires making the relative URI absolute.
  4. Don't expand the scope of the Infoset to XBase.

Resolution: (members only) The plenary has suggested that namespace names be compared as literal strings. Seehttp://lists.w3.org/Archives/Member/w3c-xml-plenary/2000Apr/0222.html (members only). Accordingly, we concur with the first three points. The second last call draft addresses the need for more clarity on namespace issues. The last point is out of scope for this group as the Infoset is owned by the XML Core WG. They have resolved to support XML Base in the infoset. Notwithstanding this, it is our belief that the Infoset_should_ incorporate XML Base processing, as it is closely correlated with the base URI property.

2.2.6. DOM: is base contextual?

Source: Lauren Wood,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0085.html.

There seems to be scope for misunderstanding whether the base URI is a property of the information item and therefore moves with it when it is moved (as for namespaceURI), or whether it is contextual.

Resolution: (members only) out of scope. XML Base provides a way for a MIME entity of the XML Media type to specify a base URI per RFC 2396. The Infoset describes how the xml:base attribute interacts with the base URI property. As an infoset "property" it is implied that base URI must stay with information items when they are moved. Neither XML Base nor the relevant parts of the Infoset constrain APIs as to how they manage dynamic manipulation or serialization of an infoset.

2.2.7. Core: XML Base like xml:space/xml:lang

Source: Paul Grosso,http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Apr/0048.html (member only). Also see linking issues list [XB7]. (members only)

References to the behavior of xml:lang and xml:space are potentially confusing and at best unnecessary and cause potential cross-dependencies that needn't be there and should be deleted.

Options from this and subsequent threads include:

  1. Delete the last sentence of each referenced paragraph.
  2. Reword things to mention xml:lang and xml:space in such a way that there is no normative dependency.
  3. Leave worded as is.

Resolution: Option 1 accepted - delete references to xml:lang and xml:space.

2.2.8. Core: XML Base scope

Source: Paul Grosso,http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Apr/0048.html (members only). Also see linking issues list [XB8]. (members only)

There is no clear positive statement about the scoping of xml:base. We should add such to the spec.

Options include:

  1. Augment the wording of the second paragraph of section 2 accordingly, making sure to point out that the scope does not extend into external entities.
  2. Leave worded as is.

Resolution: (members only) Option 1 accepted - describe scoping clearly.

2.2.9. DSig: XML Base and XPath absolutizing of URIs (2nd last call)

Source: John Boyer,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0040.html.

The XPath Recommendation states that URIs are absolutized, but no mechanism for specifying the base URL is given. I need to know as soon as possible whether an erratum to XPath will be issued to state that XBase will be the way of doing it. Alternately, will there be an erratum stating that XPath does not absolutize URIs?

Options include:

  1. Add XPath to appendix C. The default is that XML Base does not currently apply to the XPath data model.
  2. Push off problem to XPath.
  3. Do nothing.

Resolution: (members only) Option 1 and 2 accepted - describe XPath and XSLT impacts in Appendix C, and draft message on XSLT issue and forward to the XSL WG.

2.2.10. SYMM: comments on XBase (2nd last call)

Source: Lloyd Rutledge,http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000AprJun/0068.html.

  1. XBase as a recommendation fits into SMIL because SMIL is XML. We will not make any specific restrictions on the use of XBase with SMIL.
  2. We request the SML Linking WG to consider adding referential XBase functionality to the current draft, or a later version. We will not make this a requirement for using XBase with SMIL, however.
  3. If the XBase recommendation does not have referential functionality, then we may use XBase and add SMIL specific referential functionality to it.

Resolution: (members only) Declined. The proposal adds complexity and introduces many new issues. The necessity to include this feature in XML Base 1.0 is not clear.