W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2005

Re: SV: SV: strict validation of any ##other namespace

From: Kasimier Buchcik <K.Buchcik@4commerce.de>
Date: Fri, 07 Oct 2005 16:15:27 +0200
To: Bryan Rasmussen <brs@itst.dk>
Cc: ML-xml-schema-dev <xmlschema-dev@w3.org>
Message-Id: <1128694527.1272.99.camel@librax>


On Fri, 2005-10-07 at 14:52 +0200, Bryan Rasmussen wrote:
> The question then is what LibXML2's response is if the instance document
> does not have a namespace matching the schema targetNamespace. One could
> create a schema, programmatically, with a targetNamespace not in the
> instance document and import the other namespaces in. 

I assume you are referring to your example here, where we have a strict
element-wildcard, which hits an element information item in a namespace
not currently imported.

The "response" would be that the instance would be rejected as invalid.
But I'm not sure what you mean with "response": do you think of
a callback mechanism here? I.e. do you mean that the processor would
return to the code on your side and say: "hey, there's an unknown
namespace, do you have components for such a namespace at hand?" ?
The benefit I see in this would be the raise of
acquisition-efficiency in terms of memory consumption; this would
be a mechanism where components for a specific namespace are
created on demand.

I think I would simply start with the validator being fed with a
set of pre-compiled schemata to pick components from. I assume this
is the way MS has implemented this? Hmm, additionally a mechanism
to check if the sum of all the given components has any clashing

> If Libxml2 does lax validation until the point of encountering a known

Currently Libxml2 wants an element declaration to be existent for
the given validation root.

> namespace, as some processors do (XSV iirc, XMLSPY sometimes but not every
> time), then this would be a technique for Libxml2.

Regards & thanks for the input,


> -----Oprindelig meddelelse-----
> Fra: Kasimier Buchcik [mailto:K.Buchcik@4commerce.de]
> Sendt: 7. oktober 2005 14:44
> Til: Bryan Rasmussen
> Cc: ML-xml-schema-dev
> Emne: Re: SV: strict validation of any ##other namespace
> Hi,
> On Fri, 2005-10-07 at 14:14 +0200, Bryan Rasmussen wrote:
> > >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?
> > 
> > yes. I don't want to use xsi-acquisition to do the validation. As noted in
> > the earlier email, I can validate it as in the example. I want to validate
> > without using any xsi-acquisition. I can do so with the processors/API's I
> > am familiar with. Is there any processor/API which the only way to handle
> > this problem is via xsi-acquisition?
> > 
> > 
> > >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;
> > Yes, and in my experience it is present in all processors for libraries of
> > schemas, i.e. schemas that are not connected together via includes/imports
> > but can be built up as a set, i.e. the same model as xsi-acquisition but
> Ah, now I see your point; so squeezing multiple standalone schemata
> programatically into the validation process.
> > done programmatically. I am wondering if anybody knows of processors where
> > it cannot be done programmatically. 
> Yes: Libxml2 :-)
> With Libxml2 you currently need to create a combining schema which
> imports both of your schemata. I.e. you can feed Libxml2 only with
> one initial schema. If you need this and are using Libxml2,
> I recommend opening a enhancement request at
> http://bugzilla.gnome.org/buglist.cgi?product=libxml2.
> I guess it could be done for really standalone schemata in Libxml2;
> this means that they all need be complete, without any dangling
> references.
> Regards,
> Kasimier
Received on Friday, 7 October 2005 14:15:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:08 UTC