xml-dev - RE: XML-Schemas: purpose of elementFormDefault?

[johns@syscore.com (John F. Schlesinger)]

Henry wrote:
"There are clearly problems with (1), for instance because it means that
changing from a local to a global declaration for an element will have an
impact on the appearance of valid instances;"

Does this mean that it is not necessary to prefix the global elements in the
schema? If I have to prefix the global elements in the schema but not the
local elements, then changing the schema would change the form of an
instance.

In any case, am I required to prefix the root element of my document (where
I define the default namespace to be the schema's target namespace)? Or will
the validating parser recognize that even the root element is in the default
namespace? Using Roger's schema, is this then a valid instance (it is the
same as Roger's except that I declare a default namespace and remove the
qualification)?

<?xml version="1.0"?>
<BookCatalogue
  xmlns="http://www.publishing.org/namespaces/BookCatalogue"
  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
  xsi:schemaLocation="http://www.publishing.org/namespaces/BookCatalogue
                     BookCatalogue2.xsd">
  <Book>
     <Title>My Life and Times</Title>
     <Author>Paul McCartney</Author>
     <Date>1998</Date>
     <ISBN>94303-12021-43892</ISBN>
     <Publisher>McMillin Publishing</Publisher>
  </Book>
  ...
</BookCatalogue>

This is what I would like to be able to do so that poor developers that
create instances of my schema don't have to worry about namespaces, which
they don't understand (any more than I do).

Yours,
John F Schlesinger
SysCore Solutions
212 619 5200 x 219
917 886 5895 Mobile

-----Original Message-----
From: owner-xml-dev@xml.org [mailto:owner-xml-dev@xml.org]On Behalf Of
Henry S. Thompson
Sent: Monday, July 03, 2000 9:31 AM
To: Roger Costello
Cc: XML-DEV@xml.org
Subject: Re: XML-Schemas: purpose of elementFormDefault?


Roger Costello <costello@mitre.org> writes:

> "Element items validated by a global declaration must be qualified with
> a namespace URI. Control over whether element items validated by a local
> declaration must be namespace-qualified or not is provided by the form
> [attribute], whose default is provided by the elementFormDefault
> [attribute] on the enclosing schema, via its determination of {target
> namespace}"
>
> What I learned from this is best explained with an example. Here's a
> schema with one global element declaration and several local element
> declarations:
>
> <?xml version="1.0"?>
> <!DOCTYPE schema SYSTEM "part1.dtd">
> <schema xmlns="http://www.w3.org/1999/XMLSchema"
>
> targetNamespace="http://www.publishing.org/namespaces/BookCatalogue"
>       elementFormDefault="unqualified">
>     <element name="BookCatalogue">
>         <complexType>
>              <sequence>
>                  <element name="Book" minOccurs="0"
> maxOccurs="unbounded">
>                      <complexType>
>                          <sequence>
>                              <element name="Title" type="string"
>                                       minOccurs="1" maxOccurs="1"/>
>                              <element name="Author" type="string"
>                                       minOccurs="1" maxOccurs="1"/>
>                              <element name="Date" type="string"
>                                       minOccurs="1" maxOccurs="1"/>
>                              <element name="ISBN" type="string"
>                                       minOccurs="1" maxOccurs="1"/>
>                              <element name="Publisher" type="string"
>                                       minOccurs="1" maxOccurs="1"/>
>                          </sequence>
>                      </complexType>
>                  </element>
>             </sequence>
>         </complexType>
>     </element>
> </schema>
>
> My understanding is that since elementFormDefault is set to
> "unqualified" that means in the instance document I do not have to (must
> not?) qualify the local elements:

Must not.

> <?xml version="1.0"?>
> <b:BookCatalogue
>         xmlns:b="http://www.publishing.org/namespaces/BookCatalogue"
>         xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
>         xsi:schemaLocation=
>                   "http://www.publishing.org/namespaces/BookCatalogue
>                    BookCatalogue2.xsd">
>         <Book>
>                 <Title>My Life and Times</Title>
>                 <Author>Paul McCartney</Author>
>                 <Date>1998</Date>
>                 <ISBN>94303-12021-43892</ISBN>
>                 <Publisher>McMillin Publishing</Publisher>
>         </Book>
>         ...
> </b:BookCatalogue>
>
> Notice how I have qualified the global element (BookCatalogue) but not
> the local elements (Book, Title, Author, Date, ISBN, Publisher).
>
> Now I can explain where I am confused:
>
> [1] Does this mean that only the global element (BookCatalogue) gets
> validated, and not the local elements (Book, Title, Author, Date, ISBN,
> Publisher)?  If so, why would you ever want to do that - what's the
> value of the schema in such a case?

Nope, everything is validated.

> [2] It seems to me that when you create the schema, and you give a value
> for targetNamespace, then all the elements declared in the schema (both
> global and local elements) are associated with that namespace.  Is this
> not true?  So, why would you not  want to associate the local elements
> with the namespace in the instance document? The Primer tries to justify
> why you might want to do this, but I found the explanation less than
> satisfying:

Associated with, yes.  Literally 'in', not clearly.  Consider
attributes.  They are 'associated' with the namespace of their parent,
but they're not directly 'in' it, because there can be two or more
attributes with different parents but the same name which are clearly
different, with different declarations.  Just so locally declared
elements -- they are associated with a namespace via their ancestry,
but not directly 'in' it, for the same reason:  the potential of
multiple different declarations.

> To summarize, I can be a technician and blindly follow the rules - if
> the schema states elementFormDefault="unqualified" then just qualify the
> global elements in the instance document; if the schema states
> elementFormDefault="qualified" then qualify all elements in the instance
> document.  But I have no clue as to why I am doing this, when to do one
> versus the other, and what it means in terms of validation.  Can someone
> please enlighten me?

The intention is to allow the style of your _instances_, as regards
element qualification, to be independent of the style of your
_schemas_, as regards local vs top-level element declaration.

Without the control given by the 'form' attribute (and
'xxxFormDefault'), one of two situations would obtain in instances:

1) elements declared locally are like attributes: unqualified;
2) elements declared locally are like elements declared at the
   top-level: qualified (leaving the no-namespace-at-all case to one
   side).

There are clearly problems with (1), for instance because it means
that changing from a local to a global declaration for an element
will have an impact on the appearance of valid instances;

There are clearly problems with (2), because it violates the
parallelism between locally declarated elements and attributes, and
requires excessive prefixation in multi-namespace documents.

The current design is a compromise to allow experimentation with the
options.  You pays your money and you takes your choice.  There's no
difference with respect to validation:  schema-validation is attempted
on everything declared, regardless of where/how.

ht
--
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************