Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: strict validation of any ##other namespace

From: Kasimier Buchcik <K.Buchcik@---------.-->
To: Bryan Rasmussen <brs@----.-->
Date: 10/7/2005 3:49:00 PM
Hi,

On Fri, 2005-10-07 at 12:28 +0200, Bryan Rasmussen wrote:
> 
> 
> If I have a schema 1:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <schema targetNamespace="http://test.org" xmlns:b="http://test.org"
> xmlns="http://www.w3.org/2001/XMLSchema"
>  elementFormDefault="qualified" attributeFormDefault="unqualified">
> 	<element name="a" type="b:aType">
> 
> 	</element>
> 	<complexType name="aType">
> 	<sequence>
> 	           <any namespace="##other" minOccurs="1" maxOccurs="1"/>
> 	</sequence>
> 	</complexType>
> </schema>
> 
> 
> and schema 2:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <schema targetNamespace="http://test.com" xmlns:b2="http://test.com"
> xmlns="http://www.w3.org/2001/XMLSchema"
>  elementFormDefault="qualified" attributeFormDefault="unqualified">
> 	<element name="a2" type="string">
> 
> 	</element>
> </schema>
> 
> 
> and an instance 
> 
> <?xml version="1.0" encoding="utf-8"?>
> <b:a xmlns:b="http://test.org" xmlns:b2="http://test.com"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
> xsi:schemaLocation="http://test.com test2.xsd"
> >
> <b2:a2>hello</b2:a2>
> </b:a>
> 
> it is valid if I specify the schema for http://test.org programmatically (in

Do you already know that you could set the
xsi:schemaLocation="http://test.com test2.xsd" attribute
on the <b2:a2> element and set the
xsi:schemaLocation="http://test.org test1.xsd" attribute
on the document element in your instance?
I.e. it would make the schema processor to use both schemata;
thus your instance should be valid then (I didn't test this
example though).

> the validators I've tested so far). however I would like to remove
> xsi:schemaLocation and instead specify it all programmatically. I can do
> this in MSXML and .Net without a problem. I assume that the major Java
> libraries and probably projects like libxml provide the same functionality -
> am I correct in this assumption? Is there any wide-spread API that would not
> allow me to build up a set of schemas for validating the instance so that my
> processContents="strict" will validate without use of xsi:schemaLocation. 

I'm not familiar with other schema APIs than the one of Libxml2, but I'm
pretty sure that validation _without_ the use of xsi-driven schema
acquisition can be seen as a basic requirement for schema processors;
On the other hand, validation via xsi can be problematic for some
processors if they validatate in a stream-based fashion. The
"programmatically" approach has the benefit that you can compile your
schemata beforehand and reuse them, plus that you avoid any confusing
(for processors) aspects of JIT schema acquisition.

I guess Libxml2 won't work with xsi-acquisition in all cases: it
wants _all_ references to components in the schema to be resolved at a
specific moment; since this is not a requirement of the spec it will
work on only on a subset of scenarios using xsi.

Regards,

Kasimier



From brs@i... Fri Oct 07 12:22:18 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent