- From: <Noah_Mendelsohn@lotus.com>
- Date: Fri, 12 May 2000 17:16:15 -0400
- To: "Ralph R. Swick" <swick@w3.org>
- Cc: www-rdf-interest@w3.org, www-xml-schema-comments@w3.org
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:21:45 UTC