W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > April to June 2000

Last call comments on XML Base

From: Martin J. Duerst <duerst@w3.org>
Date: Wed, 28 Jun 2000 21:53:02 +0900
Message-Id: <>
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
    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

    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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:21 UTC