Re: 'form' and 'elementFormDefault' appear harmful

>>Indeed, this analogy is often cited by proponents of 
>> 'elementFormDefault=qualified'.

Ooops.  Of course I meant:

Indeed, this analogy is often cited by proponents of 
'elementFormDefault=unqualified'.

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







Noah_Mendelsohn@lotus.com
Sent by: www-xml-schema-comments-request@w3.org
05/12/00 05:16 PM

 
        To:     "Ralph R. Swick" <swick@w3.org>
        cc:     www-rdf-interest@w3.org, www-xml-schema-comments@w3.org, (bcc: Noah 
Mendelsohn/CAM/Lotus)
        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 -->
                <b>5</b>
        </n:a>

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 
'elementFormDefault=qualified'.) 

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.
http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#declare-element

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.
http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/#UnqualLocals

Received on Friday, 12 May 2000 17:33:46 UTC