- From: Martin J. Duerst <duerst@w3.org>
- Date: Wed, 28 Jun 2000 21:53:02 +0900
- To: www-xml-linking-comments@w3.org
Dear XML Linking WG, Here are some last call comments on XML Base. 1) XML Base says: >>>> A relative URI appearing in an attribute value is resolved against the base specified in the xml:base attribute appearing on the element owning the attribute, if one exists, otherwise the xml:base attribute of the nearest ancestor of the owning element having an xml:base attribute. Note that this applies to xml:base attributes themselves. <<<< The last sentence seems confusing if not completely wrong. It says to resolve the xml:base attribute against itself. This will lead to an endless loop. Please change. 2) This relates to http://www.w3.org/2000/06/xmlbase-comments-20000607#IDw_Aq1. I'm clearly not satisfied with: - The resolution of the WG - The arguments given in the disposition of comments - The implementation of the resolution of the WG in the current draft. I think the question at hand is very important for the overall XML architecture, and should be discussed more carefully. Here some details: As for the implementation of the resolution of the WG in the current draft, the WG decided to do "Note the discrepancy and warn users about it." What I would have expected was at least a note like: "Note that the fact that xml:base does not extend into external entities means that: - Replacing entity references by their replacement text can change the meaning of a document. - To avoid this, make sure that all relative URI in an external entity are governed by an absolute xml:base in that enity." I did not find any such note. The note about attribute values provided via entities or defaults is discussing another issue. The arguments given in the disposition of comments are as follows: 1. Canonicalization already breaks things, so the existence of scenarios broken solely by this feature is dubious. This argument is obviously bogus. Currently, the only use of Canonicalization is signing, which is no reason to break all the rest. Also, I don't really know where 'Canonicalization breaks things'. Canonicalization over entities and then entity replacement is not the same as overall Canonicalization, but Canonicalization was not designed for external entities, and Canonicalization over the whole document resolves entities. On the other hand, I don't see how Canonicalization breaks xml:base except for exactly the issue at hand. 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. Yes, some behaviours may be unexpected. Resolving entities may also lead to unexpected behaviours and break links. The question are: - How to define things so that the amount of dependencies in the overall architecture is minimized. - How to define things so that there is a way to get various desired behaviors. It is always possible to put an xml:base into an external entity (or to put it just around the entity refernce if the entity itself cannot be changed) if xml:base extends into external entities, but it is completely impossible to get the inverse behaviour if xml:base doesn't extend into external entities. 3. See the concerns about the wisdom of this practice raised by the comment "XBase is in conflict with RFC 2396". I do not see any such concerns in these comments. That comment is about xml:base extending from external entities. That comment provides at least two good arguments for making xml:base extend into external entities: - It is the default behavior in inclusion cases defined in RFC 2396 (5.1.2. Base URI from the Encapsulating Entity) (RFC 2396 allows to overwrite that default, but that does not at all mean that RFC 2396 provides a reason for it). - Making xml:base extend from external entities but not into external entities seems is inconsistent. 4. Suggested behavior is inconsistent with the Infoset and the XPath Data Model. I'm highly confused here. XPath assumes that all entities are resolved, has therefore no way to know entity boundaries, and has therefore no way to make sure that xml:base extends into internal entities, but not into external entities. [On rereading some things, I have a hutch that we might all want the same thing, but didn't understand each other. If that's the case, then at least I consider the phrase 'does not extend into external entities' extremely misleading. Anyway, this needs very careful check either way.] 3) There is a very minor I18N comment to change 'crosshatch' to 'number sign' (the official name of #). Regards, Martin.
Received on Wednesday, 28 June 2000 08:50:28 UTC