- 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
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:name>
<proto:dataItem>
"true"
</proto:dataItem>
<hosp:surname>Bannon</hosp:surname>
<hosp:givenNames>Michael Ryan</hosp:givenNames>
<hosp:title>Mr.</hosp:title>
</hosp:name>
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
Hi,
Thanks for the response. Unfortunately, this might not work. The
scenario
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
you
described.
So, I guess my question is, is there a way to validate against multiple
schemas without changing the schemas themselves? Actually, the only
schema
I can totally control is the prototype schema, but I doubt that helps.
Is there any way I can manipulate the parser?
thanks,
Ryan
----- 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
of
> 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
used
> 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
element?
> 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
processContents="lax',
> 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
to
> make sure your schema processor is using the two schema documents you
> want. Indeed, the terminology is that there is one "schema", which is
the
> 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
proto
> 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