Re: productions [NS 1, 10, 11, 17]

David Brownell wrote:
> 
> Four comments here ... mostly on [NS 1], a minor goof on [NS 10].
> 
> - Dave
> 
> 1.  Production [NS 1] doesn't match the preceding definition:
> 
>     - Definition says the declaration is done with an ATTRIBUTE whose
>       (name has a) prefix (that) is "xmlns".
> 
>     - Production 1 says the other side of the "Eq" is a SystemLiteral
> 
>     - But attributes have an "AttValue", allowing entity references
> 
>     Life would be simpler in several ways if production 1 were brought
>     into line with the definition (use "AttValue" not "SystemLiteral"):
> 
>     * Implementations of parsers and other XML tools wouldn't need
>       special cases to handle those attributes differently unless
>       they were actually performing namespace-related processing.
> 
>     * "Layered" implementations of namespaces could be done, vs being
>       precluded due to a need to modify attribute parsing everywhere
>       to selectively prevent entity expansion.
> 
>     * Users of namespaces would regain flexibility, such as being
>       able to put the namespace URIs into internal entities so that
>       only one copy needs to be changed as systems evolve, and so
>       that the semantically significant URIs are all in one place
>       (vs. scattered all over a large document!) for organizations
>       which prefer such information maintainence conventions.
> 
> 
>     PROPOSED FIX:  Update the production to use "AttValue":
> 
>         [1] NSDef ::= PrefixDef Eq AttValue
> 
>     However, see the next issue.
> 
> 2.  Careful reading of this text draws the conclusion, which I hope
>     is a bug, that namespace declarations may not be placed in DTDs.
> 
> 
>     PROPOSED FIX:  Eliminate production [NS 1] in the Namespace draft.
>     Modify the two productions where attribute names are used:
> 
>         [11] Attribute ::= (QName | PrefixDef) Eq AttValue
>         [17] AttDef ::= S (QName | PrefixDef) S AttType S DefaultDecl
> 
>     ALSO provide some examples of <!ATTLIST ...> declarations showing
>     "correct" usage of "xmlns" and "xmlns:foo" namespace declarations.
>     For example, corresponding to the existing example in section 2,
> 
>         <!--
>             all "x" elements, and their children, may use the
>             namespace prefix "edi".  Its meaning is fixed except
>             for children which explicitly redefine it.
>         -->
>         <!ATTLIST x
>             xmlns:edi CDATA #FIXED 'http://ecommerce.org/schema'
>             >

I would actually go further and not provide productions for the
namespace declarations at all:

In my view, the right processing model for the namespace draft is that
there's a two-stage process:

(a) first you parse an XML document exactly as per XML 1.0, with the
exception that every Name is constrained to be a QName or a NCName
according to where it occurs syntactically

(b) next you take the logical element tree produced by the first stage
in the standard XML 1.0 way and produce a new tree in which some
attributes are removed and some element type and attribute names are
expanded

I think productions are appropriate for a specification of the first
phase, but I think they lead people down the wrong track if used to
specify the second phase (witness the confusion in xml-dev) because they
suggest that it's an operation on the syntactic structure rather than
the logical structure.

This also would lead to what seems to be the appropriate error handling
strategy:

- Errors in stage (a) are syntax errors and should be treated exactly
like XML 1.0 syntax errors

- Errors in stage (b) are more akin to validity errors and shouldn't
necessarily be fatal; for example, a non-external entity reading
processor given a non-standalone document can't give a fatal error for a
undeclared namespace because it might have been declared in the external
subset
 
> 
> 3.  There's no text discussing the URI strings which are the values
>     associated with the various "xmlns" attributes.  A complete URI
>     syntax is necessary since these names are compared (as strings)
>     to determine namespace equality.

The spec needs to say how they are compared (only for the purposes of
6.4 as far as I can see).  It could just say you compare the strings
character for character.  The URN spec (RFC 2141) specifies lexical
equivalence for URNs:

5. Lexical Equivalence in URNs

   For various purposes such as caching, it's often desirable to
   determine if two URNs are the same without resolving them. The
   general purpose means of doing so is by testing for "lexical
   equivalence" as defined below.

   Two URNs are lexically equivalent if they are octet-by-octet equal
   after the following preprocessing:

           1. normalize the case of the leading "urn:" token
           2. normalize the case of the NID
           3. normalizing the case of any %-escaping

   Note that %-escaping MUST NOT be removed.


>     Are fragment identifiers allowed, or disallowed as elsewhere
>     in the XML specification?

Fragment identifiers are (as far as I remember) allowed.

James

Received on Monday, 17 August 1998 00:54:10 UTC