Re: XML Schema namespace association at the API level

Bryan Rasmussen writes:

> Most processors I'm familiar with allow some sort of 
> association of schemas
> with namespaces via the API so that one can have a list of 
> schemas maintained
> by the API seperate from the actual Schemas, allowing the 
> Processor to take
> care of scenarios such as 
> Schema # 1 uses xsd:any with processContents= strict when content of the
> document at the point where xsd:any is allowed is in namespace x without
> Schema #1 referencing Schema #2 which validates x directly. 
> 
> This basically gives the same capability that one can have with
> xsi:schemaLocation at the instance to the application. 
> 
> The thing I'm wondering about is, is this capacity defined 
> anywhere in the
> XML Schema specs? I'm looking in "4 Schemas and Namespaces: Access and
> Composition" http://www.w3.org/TR/xmlschema-1/#composition and 
> I can't find
> anything. Anywhere else? Different Processors seem to implement this
> differently, and it doesn't seem to me to be the kind of thing 
> that one would
> require of a spec, thus my question. Hope this question was clear.

Although I don't think it's anywhere near the best written part of the 
specification, this is covered in section 4.3.2 [1].  You should probably 
read the whole thing, but crucial quotes include:

* "Processors on the Web are free to undertake ·assessment· against 
arbitrary schemas in any of the ways set out in Assessing Schema-Validity 
(§5.2). However, it is useful to have a common convention for determining 
the schema to use. "

Basically, we wanted to avoid having to rewrite the schema recommendation 
just to account for the possibility that the language was being used in 
one or another context.  In a database system, for example, you may want 
to implement rules that allow the schema components or schema documents to 
be stored in the database, and you might want to allow the database to 
select appropriate versions of schemas for particular namespaces.  An 
XHTML editor might have a built in schema for XHTML, but not for other 
namespaces, and so on.  The above rule anticipates all this variability, 
and by the way allows conforming processors to do more or less what they 
want.

* "The composition of the complete schema for use in ·assessment· is 
discussed in Layer 2: Schema Documents, Namespaces and Composition (§4.2) 
above. The means used to locate appropriate schema document(s) are 
processor and application dependent, subject to the following 
requirements:"  This text is followed by four guidelines covering (1) that 
on the web, schema information is normally represented in the form of 
schema documents, I.e. what are conventionally known as .xsd files (2) 
it's OK to look for information at the URI that is the namespace name, but 
this is not required, and there may be issues in doing so (3,4) that 
xsi:schemaLocation provides hints, so you may follow those or ignore 
those, but they should not occur after first use of the namespace.

Anyway, the net of all this is that different environments are likely to 
require access to schema documents in different ways, and processors can 
do it pretty much any way they like.  Certainly, providing lists of schema 
documents through an API or command line was anticipated when the above 
rules were written.  I do apologize that they are not stated more clearly; 
 this is an area of the spec that was never polished as carefully as I 
personally would have preferred.



[1] http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#schema-loc

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 7 March 2006 22:12:23 UTC