RE: FW: User issues with Namespaces in Schema -- {form} qualified vs. unqualified, was [RE: Getting acquainted with schema]

Jeni, you said:
> 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!

The primer does say:
"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."

I realize this is not definitive and the Primer is not a normative part of the spec but I interpret this to mean that if the Schema has a target namespace you should point to it using a schemaLocation, and if it does not you should use noNamespaceSchemaLocation.


All the best, Ashok 
===========================================================
Ashok Malhotra              <mailto: ashokma@microsoft.com> 
Microsoft Corporation
212 Hessian Hills Road
Croton-On-Hudson, NY 10520 USA 
Redmond: 425-703-9462                New York: 914-271-6477 



-----Original Message-----
From: Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent: Saturday, January 12, 2002 2:27 PM
To: David Ezell
Cc: 'xmlschema-dev@w3.org'; 'w3c-xml-schema-ig@w3.org'
Subject: Re: FW: User issues with Namespaces in Schema -- {form} qualified vs. unqualified, was [RE: Getting acquainted with schema]

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 18:23:31 UTC