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

Sat 1/12/2002 2:24 PM -5:00 Jeni Tennison wrote:

>The schema validator uses lax validation against this document because
>you've used xsi:noNamespaceSchemaLocation to indicate the location of
>the schema for elements in no namespace, but the document element is
>test:Product - an element in the http://lnk.com/test namespace, for
>which there's been no schema provided.
>
>You need:
>
><?xml version="1.0"?>
><test:Product xmlns:test="http://lnk.com/test"
>              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>              xsi:schemaLocation="http://lnk.com/test
>                                  /SapphireVM1/xml/test/t1.xsd">
>  <test:Msg Type="SitRep"/>
></test:Product>

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.

After some testing of my environment, I've discovered that only
elements defined in the (wrongly) targeted schema are allowed.  If your
hypothesis were correct, then changing the prefix of Product to "foo"
(provided foo were bound to a namespace) would also induce lax validation.
That's not the case with my parser... it complains.

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! :-)

=======

So, I can't resist at least one redirect to the rest of your message.

>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.

(note: "alternative" below means my personal suggestion from the first
email.)

Yes, but it's arguable that with the alternative you *always* know if
an element is local or not.  If you know that the element is local, you
know that it's "scoped" within the namespace of the enclosing element.
XML 1.0 attributes work exactly this way -- they are in no namespace (by
default), but are within the scope of their enclosing element, so it's 
not too foreign a concept.  Also, I think the alternative helps make
naming elements easier.  Check out this example:

schema
======
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://lnk.com/test" 
        xmlns:test="http://lnk.com/test" 
        xmlns="http://www.w3.org/2001/XMLSchema"  
        elementFormDefault="unqualified">
	<element name="Product" type="test:ProductType"/>
	<complexType name="ProductType">
		<sequence>
			<element name="Msg" type="test:MsgType"/>
			<element ref="test:Msg"/>
		</sequence>
	</complexType>
	<complexType name="MsgType">
		<attribute name="Type" type="string"/>
	</complexType>
	<element name="Msg" type="string"/>
</schema>

test
====
<?xml version="1.0"?>
<test:Product xmlns:test="http://lnk.com/test" 
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
              xsi:schemaLocation="http://lnk.com/test
/SapphireVM1/xml/test/t3.xsd">
	<Msg Type="SitRep"/>
	<test:Msg>hello</test:Msg>
</test:Product>

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.  

>Horses for courses is what I say :)

No doubt about it!  In practice, both methods have their place, IMHO.

Kind regards,
David 

David Ezell
VeriFone, Inc.
Ph:  727/953-4080
Fx: 727/953-4001
[1] http://www.w3.org/TR/xmlschema-0/

Received on Saturday, 12 January 2002 16:01:45 UTC