I composed an email last Friday, and thought I had sent it. Apparently, it
got lost when my windows crashed.
First of all, I think you might want to consider Jeff's suggestion: to
preprocess your instance document to either remove "xsi:type" attributes,
or change their values.
> quick question, if redefine is used, doesn't the customer still need the
extended schema.
Not necessarily. The redefined schema has the same target namespace as the
base one, so all you need to do is to provide the proper schema document
when the parser asks for it (car.xsd in the standard environment, and
mycar.xsd in the specific ones) (using an entity resolver, for example).
> I am looking for an object-oriented way of doing things such that
superclass's get validated and subclasses only get validated if I want to
use a specific companies feature.
Well, but in Java, for an instance of the sub-class to even exist, the
subclass itself has to exist. (You can't have an instance MyCar of the
class MyCars, if the Java class loader can't find MyCars.class.) :-)
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Dean Hiller
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m> cc:
Subject: Re: dynamic
validation, is this a bug
11/21/2003 10:45
AM
Please respond to
xerces-j-user
Sandy,
quick question, if redefine is used, doesn't the customer still need
the extended schema. I am trying to avoid that....customer doesn't want
100 schemas if 100 companies are extending the schema? Maybe I am trying
to achieve the impossible? I am looking for an object-oriented way of
doing things such that superclass's get validated and subclasses only get
validated if I want to use a specific companies feature. (ie To stay
standard compliant, I always just validate against the standard). Any body
who sends me an xsi:type="ExtendedElement", I just want to make sure they
didn't take away data that the original Element had, and validate that. I
don't want to end up with 100 extension schemas to be compatible with
everyone. Thanks for all your help thus far. you have been very helpful.
thanks,
dean
Sandy Gao wrote:
4 If there is an attribute information item among the element
information
item's [attributes] whose
[namespace name] is identical to
http://www.w3.org/2001/XMLSchema-instance and whose [local name] is
type,
then all of the following must be true:
My namespace "is not" http://www.w3.org/2001/XMLSchema-instance
,
therefore 4.2 "does not apply"
Note that the "whose" refers to the attribute ("xsi:type"), not its
value.
When there is an "xsi:type", a schema processor has to, required by
the
schema spec, resolve its value to a type definition. There is nothing
Xerces (or any other schema processors) can do here.
In the scenario you described, it seems to me that you shouldn't have
used
xsi:type in the first place, for the above reason.
Have you considered my suggestion about using <redefine> at all?
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Dean Hiller
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
m> cc:
Subject: Re: dynamic
validation, is this a bug
11/20/2003 02:18
PM
Please respond to
xerces-j-user
thanks much sandy, but I am not exactly clear on that part of the
spec. To
make sure we are looking at the same part of the spec. Here is what
I read
and my interpertation below....
4 If there is an attribute information item among the element
information
item's [attributes] whose [namespace name] is identical to
http://www.w3.org/2001/XMLSchema-instance and whose [local name] is
type,
then all of the following must be true:
4.1 The �normalized value� of that attribute information item must be
�valid� with respect to the built-in QName simple type, as defined by
String Valid (�3.14.4);
4.2 The �local name� and �namespace name� (as defined in QName
Interpretation (�3.15.3)), of the �actual value� of that attribute
information item must resolve to a type definition, as defined in
QName
resolution (Instance) (�3.15.4) -- [Definition:] call this type
definition
the local type definition;
Notice #4....the namespace is identical to
http://www.w3.org/2001/XMLSchema-instance and the end saying "all of
the
following must be true" referring to 4.1, 4.2...etc.
My namespace "is not" http://www.w3.org/2001/XMLSchema-instance,
therefore
4.2 "does not apply"
I actually had this conversation with someone who was on the schema
standards body and I got the impression that this was possible. Am I
mistaken? I could not find anywhere in the spec that states a
contradictory statement, neither have I found a supporting one yet.
thanks,
dean
Sandy Gao wrote:
ie. if it only knew about a
car, it would process the car and ignore the Ford
specific
data, or
Honda specific data depending on what type of car it
actually
received.
But if your Honda car claims that "I'm a Honda, and you have to
treat
me as
a Honda" (via xsi:type), then the schema processor has no
choice but
to
tell you I'm sorry.
The schema spec is very clear on this. When there is an
xsi:type in
the
instance document, its value "must resolve to a type
definition",
which
indicates that if such resolution fails, there is an error.
You might want to consider <redefine>ing the "standard" schema,
instead of
extending it. This way, you don't need to specify "xsi:type" in
your
instance. And you can switch between the "standard" and the
"redefined"
schemas using an entity resolver (or grammar pool in Xerces).
Hope this helps,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Dean Hiller
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
m> cc:
Subject: Re:
dynamic
validation, is this a bug
11/20/2003 10:06
AM
Please respond to
xerces-j-user
yeah, can't really do that seeing as how the protocol is a
standard(ie. The whole xsd down below is the standard and we
want to
extend it and add a proprietary feature the protocol doesn't
have due
to
customer requests), and you know how slow standards change. I
really
need to accomplish it by extension. Should I ask the xerces
developers
then????
I personally don't like the any element and much prefer the
object
oriented-ness of schemas where you can extend other base types
and
add
data to them though I haven't gotten them to work yet.
ideally, an
application would just ignore extra data. ie. if it only knew
about
a
car, it would process the car and ignore the Ford specific
data, or
Honda specific data depending on what type of car it actually
received.
thanks,
dean
Mike Rawlins wrote:
At 05:27 PM 11/19/2003 -0700, Dean Hiller wrote:
good question. did a quick grep...processContents
is not
found in
the entire schema(schema is 300 pages).
Root element looks like so
<xsd:element name="Root" type="RootType/>
<xsd:complexType name="RootType">
<xsd:sequence>
<xsd:element name="Element"
type="ElementType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ElementType">
<xsd:sequence>
<xsd:element name="data1" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
Hmm, not quite what I was expecting. If you want to play
around with
another approach, you might instead do something like:
<xsd:complexType name="ElementType">
<xsd:sequence>
<xsd:element name="data1" type="xsd:string"/>
<xsd:any namespace="##any" processContents="skip">
</xsd:sequence>
</xsd:complexType>
Then, in your instance document try:
<Element>
<data1>some data</:data1>
<ava:data2>more data</ava:data2>
</Element>
I'm not sure I've got the syntax exactly correct, but
this may
be
closer to what you want and at least get you started.
This is
approach, of course, just deals with the instance
document and
schema. I've had a few problems with a similar approach
with
Xerces,
but didn't have time to track them down to closure.
However,
this or
something similar *should* work.
Mike
---------------------------------------------------------------
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com
Using XML with Legacy Business Applications
(Addison-Wesley,
2003)
www.awprofessional.com/titles/0321154940
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
