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

>  -----Original Message-----
> From: 	David Ezell  
> Sent:	Friday, January 11, 2002 6:54 PM
> To:	'xerces-j-user@xml.apache.org'
> Subject:	RE: Getting acquainted with schema
> 
> Braden:
> Your question deserves a thoughtful answer.  I hope the following qualifies
> :-).
> 
> I believe that your issue is *really* an XML1.0 + Namespaces issue.  But I
> believe that you can use a schema attribute (at least on my parser) to work
> around the problem.
> 
> Further, I take this opportunity (at the end) to show what I think is a better
> way 
> to handle this situation.
> 
> But first, your example...
> 
> It seems that your example will work if you specify
> elementFormDefault="qualified"
> in your schema, e.g.
> 
> ...
>     <schema targetNamespace="http://lnk.com/test"
>             xmlns="http://www.w3.org/2001/XMLSchema"
>             xmlns:test="http://lnk.com/test"
>             elementFormDefault="qualified">
> ...
> 
> To understand why this works, please examine the following instance document,
> which also validates against the altered schema:
> 
> test
> ====
> <?xml version="1.0"?>
> <test:Product xmlns:test="http://lnk.com/test" 
>               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>               xsi:noNamespaceSchemaLocation="/SapphireVM1/xml/test/t1.xsd">
> 	<test:Msg Type="SitRep"/>
> </test:Product>
> 
> I've removed the default namespace binding, and added prefixes to all the
> elements.  In effect, this is what the schema now says:  "all local elements
> (defined in this schema) are qualified."  Please see section 3.1 of [1].
> 
> The issue with your example is that there is a difference at the infoset level
> between being in the default namespace and being unqualified (in no
> namespace).  
> Binding the default namespace in an instance (xmlns="...") has the side effect
> 
> of making the difference between elements in the default namespace
> indistinguishable 
> visually from unqualified (in no namespace) elements.  My solution above makes
> local elements qualified, and avoids the conundrum. 
> 
> An alternative
> ==============
> Because this situation is far from desirable, I personally design my schemas
> and instance documents as follows.  (I note beforehand that this way of doing
> things goes against some people's published "best practices".)
> 
> schema
> ======
> <?xml version="1.0" encoding="UTF-8"?>
> <schema targetNamespace="http://lnk.com/test"
> xmlns="http://www.w3.org/2001/XMLSchema" 
>         xmlns:test="http://lnk.com/test" elementFormDefault="unqualified">
> 	<element name="Product" type="test:ProductType"/>
> 	<element name="GlobMsg" type="string"/>
> 	<complexType name="ProductType">
> 		<sequence>
> 			<element name="Msg" type="test:MsgType"/>
> 			<element ref="test:GlobMsg" minOccurs="0"/>
> 		</sequence>
> 	</complexType>
> 	<complexType name="MsgType">
> 		<attribute name="Type" type="string"/>
> 	</complexType>
> </schema>
> 
> instance
> ========
> <?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/t2.xsd">
> 	<Msg Type="SitRep"/>
> 	<test:GlobMsg>hello world</test:GlobMsg>
> </test:Product>
> 
> Note the following changes:  
> 1) elementFormDefault="unqualified" in the Schema (for clarity... it's the
> default).
> 2) "noNamespaceSchemaLocation" has been traded for "schemaLocation" in the
>    instance.
> 3) there is no xmlns="..." in the instance.
> 
> With those changes, elements defined in the "http://lnk.com/test" namespace
> are clearly identified in the instance.  Also, elements which are locally
> defined are clearly identified (they don't have a prefix).  I added an
> element (GlobMsg) to demonstrate the difference.  And you don't have the
> disturbing ambiguity evident in your original example.
> 
> N.B. this makes locally defined elements behave a *lot* like attributes with
> regard to namespaces.
> 
> I personally view the use of non-prefixed elements (i.e. setting xmlns="..."
> in an
> instance) to be a backward compatibility mechanism.  Others may disagree.
> 
> Hope this helps,
> David Ezell
> VeriFone, Inc.
> 
> 
> 	
> 
> 
> [1] http://www.w3.org/TR/xmlschema-0/
> 
> -----Original Message-----
> From: Braden McDaniel [mailto:braden@lnk.com]
> Sent: Friday, January 11, 2002 12:02 PM
> To: xerces-j-user@xml.apache.org
> Subject: Re: Getting acquainted with schema
> 
> 
> On Thu, 2002-01-10 at 17:29, John Utz wrote:
> > hello braden;
> > 
> > 'tis generally difficult to be helpful without a copy of your schema.
> 
> Here are pared-down versions of the schema and the document I'm trying
> to validate:
> 
>     test.xsd
>     --------
>     <?xml version="1.0" encoding="UTF-8"?>
>     
>     <schema targetNamespace="http://lnk.com/test"
>             xmlns="http://www.w3.org/2001/XMLSchema"
>             xmlns:test="http://lnk.com/test">
>     
>       <element name="Product" type="test:ProductType"/>
>       
>       <complexType name="ProductType">
>         <sequence>
>           <element name="Msg" type="test:MsgType"/>
>         </sequence>
>       </complexType>
>     
>       <complexType name="MsgType">
>         <attribute name="Type" type="string"/>
>       </complexType>
>     
>     </schema>
>     
>     
>     test.xml
>     --------
>     <?xml version="1.0"?>
>     
>     <Product xmlns="http://lnk.com/test"
>              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>              xsi:schemaLocation="http://lnk.com/test test.xsd">
>       <Msg Type="SitRep">
>       </Msg>
>     </Product>
>     
> 
> Again, here is the error message:
> 
>     [Error] test.xml:6:22: cvc-complex-type.2.4.a: Invalid content starting
> with element 'Msg'. The content must match '("":Msg)'.
> 
> I'm still thinking I'm doing something silly with namespace syntax; but
> I can't figure out what.
> 
> -- 
> Braden N. McDaniel
> Modeling/Simulation Engineer, SAIC Advanced Systems Group
> e-mail: braden.n.mcdaniel@saic.com
> telephone: (301) 927-3223 x113
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
> 
>

Received on Saturday, 12 January 2002 14:04:32 UTC