Re: CR Feedback and Implementation

I feel that what Alexander is pointing out might be used more
positively to recommend a best practice, possibly in the Primer.

Please see below.

"C. M. Sperberg-McQueen" wrote:
> 
> At 2000-12-18 07:23, Henry S. Thompson wrote:
>  > "Falk, Alexander" <al@altova.com> writes:
> 
>  >> 1) the CR should perhaps expressedly inform the reader, that any
>  >> schema document that uses a default namespace (ie no prefix) to
>  >> refer to "http://www.w3.org/2000/10/XMLSchema" must have a
>  >> targetNamespace - otherwise any type="..." or ref="..." can not be
>  >> correctly attributed to either the built-in types of XML schema or
>  >> the types that the user defines in his/her schema
> 
>  > I'm not sure I understand.  The following is perfectly valid:
> 
>  > <schema xmlns="http://www.w3.org/2000/10/XMLSchema">
>  >  <element name="foo">
>  >   <sequence>
>  >    <element name="bar" type="integer"/>
>  >    <element name="baz" type="date"/>
>  >   </sequence>
>  >  </element>
>  > </schema>
> 
> Well, actually it's not.  The 'sequence' element is not allowed there,
> you have to wrap it in a complexType element.
> 
> But consider the case where the schema author actually wants to
> refer to other things in the schema.
> 
>     <schema
>       xmlns     = "http://www.w3.org/2000/10/XMLSchema"
>       elementFormDefault="qualified"
>       >
>       <annotation>
>         <documentation>
>           This is a sample schema to demonstrate using the XML Schema
>           namespace as the default namespace for a schema without a
>           target namespace.
>         </documentation>
>       </annotation>
> 
>       <annotation>
>         <documentation>This declaration is fine.</documentation>
>       </annotation>
> 
>       <complexType name="tA">
>         <sequence><element type="integer" name="i"/></sequence>
>       </complexType>
> 
>       <annotation>
>         <documentation>
>           These declarations, on the other hand, are unlikely to be
>           what any schema author will have in mind.
> 
>           Complex types tB and tC won't be successful in saying what
>           types they are derived from.
>         </documentation>
>       </annotation>
> 
>       <complexType name="tB">
>         <complexContent>
>           <extension base="tA">
>         <sequence><element type="integer" name="j"/></sequence>
>           </extension>
>         </complexContent>
>       </complexType>
> 
>       <complexType name="tC">
>         <complexContent>
>           <extension base="tB">
>         <sequence><element type="integer" name="k"/></sequence>
>           </extension>
>         </complexContent>
>       </complexType>
> 
>       <annotation>
>         <documentation>
>           Element type 'ace' will have trouble making clear which
>           elements are supposed to be its children.
>         </documentation>
>       </annotation>
> 
>       <element name="ace">
>         <complexType>
>           <choice maxOccurs="unbounded" minOccurs="0">
>         <element ref="A"/>
>         <element ref="B"/>
>         <element ref="C"/>
>         <element ref="X"/>
>           </choice>
>         </complexType>
>       </element>
> 
>       <annotation>
>         <documentation>
>           Element types A, B, C, and X will have trouble saying
>           what type they have.
>         </documentation>
>       </annotation>
> 
>       <element type="tA" name="A"/>
>       <element type="tB" name="B"/>
>       <element type="tC" name="C"/>
>       <element type="tA" name="X"/>
> 
>     </schema>
> 
> This is legal, but not useful. 

However, here's a version that is (I hope) both legal and useful:

    <xsd:schema
      xmlns:xsd     = "http://www.w3.org/2000/10/XMLSchema"
      >
      <xsd:annotation>
        <xsd:documentation>
          This is a sample schema to demonstrate using the XML Schema
          namespace with an explicit prefix for a schema without a
          target namespace.  The same style can of course be used also
          for a schema that does have a target namespace, just by
          using a default namespace declaration for that target NS
          to allow unprefixed reference to global definitions and
          declarations in that NS (if desired).

          Note also that the default of "unqualified" has been taken
          for elementFormDefault, since it would be hard to know what
          to qualify the local names by in the instance, in the absence
          of a target NS.
        </xsd:documentation>
      </xsd:annotation>

      <xsd:annotation>
        <xsd:documentation>This declaration is fine.</xsd:documentation>
      </xsd:annotation>

      <xsd:complexType name="tA">
        <xsd:sequence><element type="xsd:integer" name="i"/></sequence>
      </xsd:complexType>


      <xsd:annotation>
        <xsd:documentation>
          The following declarations are also fine. 

          Complex types tB and tC will be successful in saying what
          types they are derived from.
        </xsd:documentation>
      </xsd:annotation>

      <xsd:complexType name="tB">
        <xsd:complexContent>
          <xsd:extension base="tA">
            <xsd:sequence><xsd:element type="xsd:integer" 
                                       name="j"/>
            </xsd:sequence>
          </xsd:extension>
        </xsd:complexContent>
      </xsd:complexType>

      <xsd:complexType name="tC">
        <xsd:complexContent>
          <xsd:extension base="tB">
            <xsd:sequence><xsd:element type="xsd:integer" 
                                       name="k"/>
            </xsd:sequence>
          </xsd:extension>
        </xsd:complexContent>
      </xsd:complexType>

      <xsd:annotation>
        <xsd:documentation>
          Element type 'ace' will have no trouble making clear which
          elements are supposed to be its children.  They are the
          global elements defined in this schema.
        </xsd:documentation>
      </xsd:annotation>

      <xsd:element name="ace">
        <xsd:complexType>
          <xsd:choice maxOccurs="unbounded" minOccurs="0">
            <xsd:element ref="A"/>
            <xsd:element ref="B"/>
            <xsd:element ref="C"/>
            <xsd:element ref="X"/>
          </xsd:choice>
        </xsd:complexType>
      </xsd:element>

      <xsd:annotation>
        <xsd:documentation>
          Element types A, B, C, and X will have no trouble saying
          what type they have.
        </xsd:documentation>
      </xsd:annotation>

      <xsd:element type="tA" name="A"/>
      <xsd:element type="tB" name="B"/>
      <xsd:element type="tC" name="C"/>
      <xsd:element type="tA" name="X"/>

    </xsd:schema>

The xsd: prefixes are no more visually attractive than the rest of
our syntax, but they have the advantage that if habitually used, they
remove the traps associated with default namespaces - e.g. that they 
can capture things you didn't intend to be qualified at all, that they
are tricky to switch to other nested default namespace declarations
because a nested NS decl captures its own element name, and, last but
not least, they are not recognized by XPath and XSLT which require all
qualified elements to be explicitly prefixed when referenced in their 
world.

Also, the xsl: prefix is so commonly seen in examples of XSLT that
I don't foresee an outcry if an xsd: prefix becomes the normal practice
in writing schemas.  I hoped for a long time for something more
elegant, but I now strongly recommend people to use an xsd: prefix
uniformaly and avoid as many of the namespace complexities as possible.


> The schema I use (i.e. the schema
> provided by our spec) for the XML Schema namespace does not declare
> complex types named tA, tB, or tC, nor elements named A, B, C, or X.
> So a document which tries to use this schema won't be able to use
> anything declared here.
> 
> It's true that on some occasions one might successfully use the XML
> Schema namespace as the default namespace in a schema document without
> a target namespace, as illustrated by Henry's example.  But precisely
> because my example schema document is not illegal and won't by itself
> raise any error messages, I think a casual warning (a bit weaker than
> suggested by Alexander Falk) is probably a good idea: "Note that if
> the XML Schema namespace is used as the default namespace, the schema
> document itself should almost always have an explicit target
> namespace.  Otherwise, it will be impossible to refer to anything declared
> in the schema from elsewhere in the schema."  Perhaps the warning belongs
> in the Primer, rather than the Structures spec.

A more positive statement would be something like:

"Whether or not a schema has a target namespace, a good uniform
convention for writing schemas is to introduce a prefix such as
xsd for the XML Schema namespace, and to use it when writing all 
schema elements, e.g. <xsd:complexType>.  Although it is possible to 
make careful use of a default namespace for XML Schema in cases where
the schema being designed has a target namespace, it is definitely 
inadvisable in cases where there is no target namespace and a 
definition or declaration needs to refer to another component of the 
schema, since some awkward additional namespace declarations would 
have to be introduced to make this possible."

Is anyone else finding this?

Thanks,

  David

Received on Wednesday, 27 December 2000 17:40:03 UTC