Editorial: must not vs. fatal error

Seection 3.1 states:

Fragment identifiers must not <http://www.w3.org/TR/xinclude/#dt-must> 
be used.


However, section 6.2 states:

An application conforms to XInclude if it:

    *

      supports [XML 1.0] <http://www.w3.org/TR/xinclude/#XML>,
      [Namespaces in XML] <http://www.w3.org/TR/xinclude/#XMLNS>, the
      [XML Information Set] <http://www.w3.org/TR/xinclude/#XMLIS>, [XML
      Base] <http://www.w3.org/TR/xinclude/#XMLBase>, the [XPointer
      Framework] <http://www.w3.org/TR/xinclude/#XPCore>, and the
      [XPointer element() scheme] <http://www.w3.org/TR/xinclude/#XPElement>

    *

      stops processing when a fatal error
      <http://www.w3.org/TR/xinclude/#dt-error> is encountered.

    *

      observes the mandatory conditions (must
      <http://www.w3.org/TR/xinclude/#dt-must>) set forth in this
      specification, and for any optional conditions (should
      <http://www.w3.org/TR/xinclude/#dt-must> and may
      <http://www.w3.org/TR/xinclude/#dt-must>) it chooses to observe,
      observes them in the way prescribed

    *

      performs markup conformance testing according to all the
      conformance constraints appearing in this specification.

It seems to me that "must nots" and musts are intended to apply to 
processor behavior, whereas fatal errors normally describe document 
content. If this interpretation is correct, I think the "must not" in 
3.1.1 should instead be a fatal error. e.g.

It is a fatal error if a fragment identifier is used in the value of an 
href attribute.

If my interpretation of section 3.1 is not correct, and this is not a 
fatal error, then I would request that the spec further elaborate on 
what implementations are supposed to do when encountering a fragment ID 
in an href attribute.

--
Elliotte Rusty Harold

Received on Sunday, 6 June 2004 19:06:53 UTC