- 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