W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2002

Re: validate against multiple schemas

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 20 Sep 2002 12:05:02 -0400
To: "Michael Ryan Bannon" <mrbannon@uwaterloo.ca>
Cc: xmlschema-dev@w3.org
Message-ID: <OF9351403E.C97CC814-ON85256C3A.00569336@lotus.com>

Well, the problem is, if you have a schema for "hospital" that explicitly 
says "no attributes" or "only attributes X and Y", then your new 
proto;dataItem attribute DOES violate the definition of that element, so 
in that case the answer is no.

There is actually a bit more trickery you can do if what you're adding is 
an element:

    <hosp:givenNames>Michael Ryan</hosp:givenNames>

Presumably, this will still correctly fail to validate as a hosp:name, 
because you have indeed added an element that (I presume) is not allowed 
by the hospital schema.  Where you can make a bit of progress is that the 
schema spec says that, at least in principle, you can chose any particular 
element to start validation.  So, in principle, you could point your 
processor to the <proto:dataItem> element and validate just that.    How 
you actually do that would depend on your processor, and I doubt that many 
support it today.  You might find a processor that would let you read in 
the overall document into, for example, a DOM, and you might find a 
validator that would let you take the DOM node representing 
<proto:dataItem> is input.  It's barely worth it with this trivial 
element, but might be useful for something more complex.

There is one other way to do this, that might work.  You could write your 
own schema that types <hosp:name> as <any> with <anyAttributes> and 
processContents="lax", but copy some of the other hospital declarations, 
This might give you some flexibility, but I'm guessing you're a bit new to 
schemas (my apologies if not), and it might take a bit of learning to 
understand how this works and how to control it. 

The bottom line, though, is that you have done something that the HOSPITAL 
folks say is illegal (I presume) by adding your attribute, and if you use 
the official hospital schema, the schema processor is doing it's job by 
rejecting it.

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

"Michael Ryan Bannon" <mrbannon@uwaterloo.ca>
09/20/02 10:56 AM

        To:     <noah_mendelsohn@us.ibm.com>
        cc:     <xmlschema-dev@w3.org>
        Subject:        Re: validate against multiple schemas


Thanks for the response.  Unfortunately, this might not work.  The 
is the following:

1) I recieve an XML file that uses the hospital schema
2) I want to mark it up with a prototype attribute
3) I add the prototype attribute and schema definition to the XML file

The problem is, I will have no prior knowledge of the hospital schema. The
"name" element may not (most likely will not) allow those two scenarios 

So, I guess my question is, is there a way to validate against multiple
schemas without changing the schemas themselves?  Actually, the only 
I can totally control is the prototype schema, but I doubt that helps.

Is there any way I can manipulate the parser?



----- Original Message -----
From: <noah_mendelsohn@us.ibm.com>
To: "Michael Ryan Bannon" <mrbannon@uwaterloo.ca>
Cc: <xmlschema-dev@w3.org>
Sent: Friday, September 20, 2002 10:41 AM
Subject: Re: validate against multiple schemas

> Michael Ryan Bannon asks:
> >> What I want to happen is for a parser to validate all the "hospial"
> >> elements agains the "hospital" schema and the "proto" attribute
> >> against the "proto" schema.
> The answer is yes absolutely, this is the intended usage although some 
> your terminology is a bit off.  The correct way to say it would be:
> "What I want to happen is for a parser to validate all the "hospial"
> elements agains the "hospital" schema document and the "proto" attribute
> against the "proto"  schema document."  I explain why these terms are 
> below.  First, here's what you need to do:
> Your example was:
> <?xml version="1.0"?>
> <patientRecord
> xmlns:hosp="http://www.swen.uwaterloo.ca/~mrbannon/HOSPITAL"
>     xmlns:proto=http://www.swen.uwaterloo.ca/~mrbannon/PROTOTYPE
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>   <hosp:name proto:dataItem="true">
>    <hosp:surname>Bannon</hosp:surname>
>    <hosp:givenNames>Michael Ryan</hosp:givenNames>
>    <hosp:title>Mr.</hosp:title>
>   </hosp:name>
> </hosp:patientRecord>
> The main question is: what' is the declaration for the hosp:name 
> That hosp schema better do one of two things to make this work:
> * It could specify <xsd:anyAttribute processContents="strict">, which
> would allow any attribute, including proto:dataItem, and would force
> validation of any attribute found (you can also use 
> but that's a bit trickier....no need in this example.)
> * It could explicitly <import> the proto namespace, and then in the
> declaration for hosp:name list:
>         <xsd:attribute ref="proto:dataItem"/>
> (I've presumed all the obvious namespace declarations.)  You then have 
> make sure your schema processor is using the two schema documents you
> want.  Indeed, the terminology is that there is one "schema", which is 
> combination of information from those two documents.  Your document is
> then validated against the net schema, which is for both namespaces. One
> way to tell your processor where to find the schema for proto is to
> include a hint in the import:
>         <import
> targetNamespace="http://www.swen.uwaterloo.ca/~mrbannon/PROTOTYPE"
>                      schemaLocation="...uri of your schema file for 
> goes here"/>
> The processor doesn't have to honor the hint, but many do.
> I hope this helps.
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
Received on Friday, 20 September 2002 12:07:26 UTC

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