Sandy Gao wrote:
I need to think through xsi:type more.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.
So I still need to provied mycar.xsd, is that correct? With my use case, this doesn't work cleanly as I don't want to have to have companyXcar.xsd, companyYcar.xsd, etc.(around 10 companies).quick question, if redefine is used, doesn't the customer still need theextended 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).
Well, actually I was thinking more in terms of XML API's for Binding. .NET I think is doing something similar and java has JAXB. Basically, when I get a CompanyXCar xml object, it is marshalled into Car.class object if CompanyXCar does not exist and Car is validated. If CompanyXCar does exist, it is unmarshalled into a CompanyXCar object. It is very clean for customers of our xml api. All our customers would have to do is generate the all the objects using JAXB (I believe there is a product in C++ too), and they get all their objects. If they just want to be compliant with the standard, they only generate standard objects and our extensions would be marshalled into standard objects. If they use the extensions, they would generate those from the extended schema, and just use the objects...no need to do any xml development anymore in any language. It is very slick. Unfortunately, I had to start talking to the w3c group. Luckily the w3c TAG is currently working on forward/backward compatibility right now.I am looking for an object-oriented way of doing things such thatsuperclass'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.) :-)
I think this would be a very slick mechanism for our customers and make it very easy for them to use our api without ever having to do XML development. They just generate the objects in their target language. Without this feature though, it makes it hard. Need some type of new feature to be compliant with this type of parser. Just thought I would explain where I was going. thanks for all your suggestions,
dean
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]
