W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2004

Re: Namespace problem

From: Burak Emir <Burak.Emir@epfl.ch>
Date: Wed, 18 Aug 2004 10:35:41 +0200
Message-ID: <412314DD.1030003@epfl.ch>
To: Volker.Zink@porabo.ch
CC: xmlschema-dev@w3.org

Hello Volker,

1. which parser are you using? Is it possible that is has 
namespace-support disabled?

2. [unsure] does it work when you remove the "plem:" prefix from the 
schema (both in root and in the type="plem:" attribute) ?

I am implementing a schema validator myself, and I stubbed my toe on a 
similar thing. The fact is, common sense would suggest namespaces make 
element names unique by adding the URI to them. It would then be ok to 
forget the namespace prefixes, representing element names as {uri:name}.

Unfortunately, in XML schema this is not the entire truth - one has to 
remember also the prefixes, because they appear in attribute values. I 
consider this a real shortcoming of the XML schema definition language - 
it is counter-intuitive, because one is forced to mix the structure of 
the definition (a declaration xmlns:foo="..." in the root element 
<schema ...>) with the structure of the instances (as in type="foo:...").

Since there is no element "plem:...", it could be that your software 
just "forgot" about that prefix, and defaulted it to "" - in any case, a 


Volker Zink wrote:

> when validating (strict) the included XML-document versus the included 
> schema i get following error (its the only error):
> Invalid per cvc-complex-type.1.2.4:
>   element {grips://xml.recom-verlag.de/comm/plem}:fallImportExport not 
> allowed here (1) in element 
> {grips://xml.recom-verlag.de/comm/plem}:fallInterface, expecting 
> [{None}:fallImportExport]:
> I think by setting the targetNamespace in the schema, the elements and 
> types are in the namespace "grips://xml.recom-verlag.de/comm/plem", so 
> why is the namespace 'None' expected (and whats the meaning of the 
> []-brackets)?
> Thanks
> Volker Zink

Received on Wednesday, 18 August 2004 08:49:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:23 UTC