The easiest fix to this is to include elementFormDefault="qualified" in your 
xs:schema attribute list.  e.g.:

<xs:schema
    elementFormDefault="qualified"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.foo.com"
    xmlns:foo="http://www.foo.com">
    ...

Without it the local element bjork is unqualified.  You can consider an 
element name to have two parts, a namespace and local name.  In the 
unqualified case the namespace is empty and the local part is 'bjork'. 
That's what the XML parser wants to find.  However, as you have set the 
default namespace to http://www.foo.com, what the parser finds is an element 
with namespace equals http://www.foo.com and local part is bjork; which 
obviously don't match.

Making elementFormDefault="qualified" will make the parser expect an element 
with namespace equals http://www.foo.com and local part is bjork, and so it 
will work.

HTH,

Pete Cordell
Codalogic
For XML C++ data binding visit http://www.codalogic.com/lmx/
----- Original Message ----- 
From: "Gavin Kistner" <>
To: "Michael Kay" <>
Cc: <xmlschema-dev@w...>
Sent: Friday, March 14, 2008 8:34 PM
Subject: RE: Composition by extension in namespaced schema


>
> On Friday, March 14, 2008, at 12:24PM, "Michael Kay" <mike@s...> 
> wrote:
>>> I need to use a targetNamespace (or is it an xmlns?) in my
>>> schema so that I can validate other files without having to
>>> add noNamespaceSchemaLocation to those files. Can someone
>>> help me understand the core issue here, and (especially) how
>>> to modify the file to accomplish the goal?
>
>>The type is in a namespace, so the reference to it needs to be prefixed:
>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>> targetNamespace="http://www.foo.com/"
>>  xmlns:tgt="http://www.foo.com/">
>>>   <xs:complexType name="mammal" />
>>>   <xs:element name="dog">
>>>     <xs:complexType><xs:complexContent>
>>>     <xs:extension base="tgt:mammal" />
>>>     </xs:complexContent></xs:complexType>
>>>   </xs:element>
>>> </xs:schema>
>
> Thank you again; that (oh so simple, and now understandable, change) fixed 
> the validation of the XSD itself. However, when I try to validate an XML 
> document against this schema, I get a new (confusingly-reported) error:
>
> <!-- foo.xsd -->
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
> targetNamespace="http://www.foo.com" xmlns:foo="http://www.foo.com">
>  <xs:element name="root">
>    <xs:complexType>
>      <xs:sequence>
>        <xs:element ref="foo:native"/>
>        <xs:element name="bjork"><xs:simpleType><xs:restriction 
> base="xs:string" /></xs:simpleType></xs:element>
>      </xs:sequence>
>    </xs:complexType>
>  </xs:element>
>  <xs:element name="native"/>
> </xs:schema>
>
> <!-- test.xml -->
> <?xml version="1.0" encoding="UTF-8"?>
> <root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xsi:schemaLocation="http://www.foo.com foo.xsd" 
> xmlns="http://www.foo.com">
>  <native />
>  <bjork>Hello There</bjork>
> </root>
>
> <!--
>  SystemID: E:\test.xml
>  Location: 6:4
>  Description: cvc-complex-type.2.4.a: Invalid content was found starting 
> with element 'bjork'. One of '{bjork}' is expected.
>  URL: http://www.w3.org/TR/xmlschema-1/#cvc-complex-type
> -->
>
>
> As shown above, the 'native' element in the sequence works with the 
> namespace, but the inline element does not. Is this a true validation 
> error, or is this a bug in the validator that I need to work around by 
> just moving all elements to be defined at the top level?
>
>
> 



From noah_mendelsohn@u... Sat Mar 15 02:20:12 2008
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.63)
	(envel