Re: 'form' and 'elementFormDefault' appear harmful

> From: Noah_Mendelsohn@lotus.com
> To: "Ralph R. Swick" <swick@w3.org>
> Cc: www-rdf-interest@w3.org, www-xml-schema-comments@w3.org
> Message-ID: <OFC9200AAA.D00CBC23-ON852568DD.00744BD0@lotus.com>
> Date: Fri, 12 May 2000 17:16:15 -0400
> Subject: Re: 'form' and 'elementFormDefault' appear harmful

> <snip/>
>
> Now, having prepared this glib explanation, I will admit to one point of
> discomfort on my part.  I had expected that we had put into the augmented
> infoset a contribution indicating the element declaration for <b>, from
> which you could surely determine its local scoping.  I am a little
> surprised to see that we only supply the type, which in the example above
> may be something as simple as integer.
>
> Note that this entire discussion has a direct analogy in the case where
> 'elementFormDefault=qualified'.  You still do not know whether the element
> is locally scoped until you check the schema, and namespaces are still
> assigned exactly according to the rules of the namespaces recommendation.
>
> So, I think the fundamental design is sound.  I would like to hear from
> other members of the schema workgroup whether we actually have the infoset
> contribution quite right.  Henry?

Thanks, Noah, for this clear explanation - the association
of namespace URIRef (if any) with each element and attribute
name has already been carried out in forming the Infoset
that is input to schema validation.  All we can do then is
check that this usage is consistent with the schema's
type definitions and element and attribute declarations.

One further clarification may help some readers: when we say
that an element or attribute name has local scope, we mean that
it has been declared using the form <element/attribute
name='...' ...> inside a complex type definition.  Its
declaration then needs to be unique only within the local
scope of that type definition (there can be other declarations
of that local element name in different positions in the
content model, but they must have the same type).

So when schema validation has in hand an element or attribute
and believes that it should match a local declaration, then

(a) by default, or if within the scope of
element/attributeFormDefault= 'unqualified' respectively,
that element/attribute name should not be
carrying in the Infoset any qualifying URIRef;

(b) if within the scope of element/attributeFormDefault=
'qualified' respectively, that element/attribute name should
be carrying in the Infoset the URIRef of the targetNamespace
of the type definition to which it is local.

These options are to simplify different styles of usage, e.g.

(a) data transfer between type systems that have local names
for fields of classes, or columns of tables, where the
corresponding XML Schema uses entirely local declarations
apart from a top-level element declaration for the root.
Instances then use a namespace declaration and a prefix for
the root, and unqualified element and attribute names
elsewhere (no prefix, no default namespace declaration) -
even where types from several namespaces are being used
in the same XML document.

(b) use of a combination of locally scoped and globally
scoped names (as in the Schema for Schemas) with similar
qualification in the instance, especially when type
definitions and element declarations are in the same
namespace and a default namespace declaration allows them
all to appear unprefixed.

                  ---0---

Now to respond to your last question, Noah, about the
PSV-Infoset contribution - maybe for simplicity what we
have will suffice, since the element/attribute declaration
should be readily derivable, if the following reasoning
is correct.

The root element of an instance must have a global element
declaration (if any - option 1 of validation in Structures
section 7.2 is to ignore the element name and go straight
for validation against a given type definition).

Any other element or attribute must then be validated against
the "actual" type definition of its immediately containing
element, which is already present in the PSV-Infoset.

Thanks,

  David

Received on Tuesday, 16 May 2000 14:05:01 UTC