- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sat, 12 Jan 2002 22:26:47 +0000
- To: David Ezell <David_E3@Verifone.Com>
- CC: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>, "'w3c-xml-schema-ig@w3.org'" <w3c-xml-schema-ig@w3.org>
Hi David, > Thanks for the correction to the example. It was an oversight/typo > that I left the "noNamespaceSchemaLocation" in the document. > However, I'm not sure that you're right about "lax validation" being > the culprit. I believe that lax validation can only be declared as > part of an "any" particle. So here's an alternative explanation. You are right that the only time you explicitly tell a validator to do a lax validation of an element is through the any particle. However, I believe that a validator will perform lax validation in other situations (and in particular this one, where the document element does not have an element declaration). I think that this case is covered by option 3 of Section 5.2 of the XML Schema Structure Rec (http://www.w3.org/TR/xmlschema-1/#validation_outcome): "The processor starts from Schema-Validity Assessment (Element) (§3.3.4) with no stipulated declaration or definition, and either ·strict· or ·lax· assessment ensues, depending on whether or not the element information and the schema determine either an element declaration (by name) or a type definition (via xsi:type) or not." I read this as saying that if an element declaration (by name) or a type definition (via xsi:type) is available for the document element, then the validator begins to validate with 'strict' validation. If neither of these are available, the validator starts to validate with 'lax' validation. Also, just after Validation Rule: Schema-Validity Assessment (Element) (http://www.w3.org/TR/xmlschema-1/#cvc-assess-elt), it says: "If the item cannot be ·strictly assessed·, because neither clause 1.1 nor clause 1.2 above are satisfied, [Definition:] an element information item's schema validity may be laxly assessed if its ·context-determined declaration· is not skip by ·validating· with respect to the ·ur-type definition· as per Element Locally Valid (Type) (§3.3.4)." Clause 1.1 and Clause 1.2 cover discovering an appropriate element declaration or type definition for the element, respectively. > Further examination brought out another anomaly... From section 5.6 > of the Primer [1]: > > "A schema is not required to have a namespace (see Section 3.4) and > so there is a noNamespaceSchemaLocation attribute which is used to > provide hints for the locations of schema documents that DO NOT HAVE > TARGET NAMESPACES". [emphasis mine] > > The schema targeted *has* a targetNamespace, and would seem to be in > violation of this statement. My parser/environment seems to ignore > that rule, and figures out that the "test" prefix means stuff in the > target schema, even though it's not supposed to. In short, it's a > helpful (if somewhat embarrassing) bug! :-) Heh. Actually, I can't find anything in the XML Schema Structure Rec that explicitly says that the xsi:noNamespaceSchemaLocation attribute has to point to a schema with no target namespace! (It's implied, but there aren't any of the usual logical rules about it.) So probably it's perfectly valid for a schema validator to just pick up on whatever schemas it can locate through whatever attributes it can find and create something from that... which could explain why you found that it was validating those elements. >>At least if all local elements are qualified you know that if an >>element is from the http://lnk.com/test markup language, it will be >>in that namespace. > > Yes, but it's arguable that with the alternative you *always* know > if an element is local or not. Absolutely. If you use qualified local elements, then locally declared and globally declared elements appear in exactly the same way. If you use unqualified local elements then they look the same. In the kind of applications that I deal with, you really don't care if an element is declared locally or globally, because the schema is just a way of describing the constraints on a markup language. I guess in the type of applications that you're using, the schema provides extra information to your application. I'd be interested in how you use the fact that an element is local or global - how it changes how you process that element? > Here it's pretty clear that there are two elements in the > test:Product element with the localName Msg. The one with global > scope may have been imported as part of another schema (into the > same namespace). For me, doing it this way makes it easier to reuse > components of my vocabulary without having to create new namespaces > just because I want to have a local element of the same name; or > possibly I don't know until rev 2 of my vocabulary that I've > overloaded some name, and so have a choice of renaming my element or > trashing everything and giving it a new namespace. Granted, "Msg" is > a really bad example; elements with names like "Employee" or > "Address" would be more common. I think that what you're saying is that having unqualified local elements is beneficial because it enables you to have two elements with the same local name but different content, in different namespaces. What do you do when you want to add a third element with the same local name but different content? ;) Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Saturday, 12 January 2002 17:26:53 UTC