W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2000

Re: 'form' and 'elementFormDefault' appear harmful

From: <petsa@us.ibm.com>
Date: Wed, 17 May 2000 13:29:59 -0400
To: Noah_Mendelsohn@lotus.com
cc: "Ralph R. Swick" <swick@w3.org>, www-xml-schema-comments@w3.org
Message-ID: <852568E2.00601D11.00@D51MTA03.pok.ibm.com>
You have done a great job explaining the elementFormDefault feature.
Thank you for doing that!

But there is another, and in my view, more important point here.  The
most frequent comment we have gotten about the Schema spec is that it is
too large
and too complex.  A guy just stopped me in the hall and said "can't you
make Schema simpler?"  In my personal (not IBM) viewpoint
is a feature we could have easily done without.  We just flip a coin and
pick one option or the other.  Sure, this will make some people unhappy
but, again in my view, this is a minor feature and the unhappiness will
also be minor.  It would be outweighed by the simplification of the spec
which would impact many, many people some of whom are trying to get into
For these people lowering the barrier to entry is of prime importance.

All the best, Ashok

Noah_Mendelsohn@lotus.com@w3.org on 05/12/2000 05:16:15 PM

Sent by:  www-xml-schema-comments-request@w3.org

To:   "Ralph R. Swick" <swick@w3.org>
cc:   www-rdf-interest@w3.org, www-xml-schema-comments@w3.org
Subject:  Re: 'form' and 'elementFormDefault' appear harmful

I understand your confusion, but I think you have misinterpreted the
schema specification.  The namespace qualification or lack thereof for any
element in a document to be validated is established according to the
rules of the Namespaces Recommendation, and does not change during the
course of schema validation.  Indeed, validation is defined as an
operation on an infoset, so all the mechanisms of namespace defaults and
so on are applied before schema validation begins.

I think your confusion is about the case where we have an instance
document that looks like this:

        <n:a xmlns:a="uria">
                <!-- element b is neither
                  prefixed nor qualified -->

First of all, neither XML 1.0 nor namespaces itself introduces any notion
of local scoping for elements.  Therefore, it is not surprising that we
cannot tell whether the declaration for <b> is locally scoped.  Whether
you use qualified or unqualified forms, local scoping is always an
artifact of schema processing, never fundamental to the instance.

Furthermore, and I think this is your point of confusion, even if the
declaration for <b> is locally scoped within the declaration for <n:a>,
<b> itself is still not considered to be in a namespace.  We cannot change
that; the namespaces recommendation says it is not.  So, the namespace URI
in the infoset for the element (or lack of namespace URI in this case) is
not changed by validation.  What does happen as a result of the validation
is that additional information is added to the infoset, and from that
information you can make some determination as to the actual declaration
for <b>.  So, it is not <b> itself which appears in a namespace, but <b>
is associated during validation with definitions and declarations which
may well be in the target namespace "uria".

Note too that there is a direct analogy to the treatment of attributes per
the namespaces recommendation: the typical attribute appears unqualified,
but has a definition scoped to a possibly namespace qualified element on
which it appears (you know it is scoped that way because two attributes
named 'atr' appearing on two different elements in the same namespace can
have two different default values.  I don't think anyone disputes this.
The namespaces recommendation makes clear that such unprefixed attributes
are not specifically in the namespace of the element on which they appear,
although a non-normative concept of namespace partition is discussed.
Indeed, this analogy is often cited by proponents of

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?

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"Ralph R. Swick" <swick@w3.org>
Sent by: www-xml-schema-comments-request@w3.org
05/12/00 04:30 PM

        To:     www-xml-schema-comments@w3.org
        cc:     www-rdf-interest@w3.org, (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        'form' and 'elementFormDefault' appear harmful

The control over namespace qualification provided by form and
elementFormDefault appear, if I understand them correctly, to
change default namespace processing in a very fundamental way.

It appears that the default case, 'elementFormDefault=unqualified'
would change what a processor currently understands to be the
namespace of some unqualified elements within the scope of
some parents.  To understand which unqualified elements are bound
to which namespaces requires schema processing.

This seems to make default namespace declarations unuseable, (or,
conversely, to make schema processing a requirement rather than
an option).  Neither conclusion feels good to me.  I hope I'm
fundamentally misunderstanding, Schema Structures section 4.3.2
and that the statement in the final paragraph of Schema Primer
section 3.1 is inaccurate.
Received on Wednesday, 17 May 2000 13:30:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:47 UTC