[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in ins tance
Will someone please alter my specific example as Matt describes and post it back to the list? I think it's important to see a concrete, valid example. -----Original Message----- From: Matthew Gertner [mailto:matthew.gertner@acepoint.cz] Sent: Wednesday, February 05, 2003 9:07 AM To: Burcham, Bill; Lisa-Aeon; UBL-NDR Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in instance Yes, the cascading problem is there, and I don't see any way around it. You have to pay somewhere... Assuming this accurately represents the decision of the NDRSC (perhaps a big assumption), your examples should be correct if all xsi:type attributes except the one pointing to the p3 namespace are removed, no? > -----Original Message----- > From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com] > Sent: Wednesday, February 05, 2003 3:57 PM > To: 'Matthew Gertner'; Lisa-Aeon; UBL-NDR > Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in > instance > > If I understand you, then for instance, if a user needed to eliminate zip > code from an Address (assuming that Zip code was "required") then that > user is going to suddenly be using ur-schemas for all the doc-types > that use > Address. This is the "cascade" effect we talked about in Barcelona. > > I don't have a solution to this problem -- I just want to be sure we're > all > aware of it. > > For those who haven't read the example: it defines an ur-schema with a few > types, one of which, CountryCode has a Code element. The "UBL" schema is > derived from that one (by _restriction_) and makes some of the elements > required (they're all optional in the ur-schema by definition). I then > define a "third-party" schema that derives from the ur-schema and changes > CountryCode so as to replace the Code element with an element called > "NewElement". Two instances are provided: a vanilla UBL one and a > "third-party" one. > > In my original message (the one Matt just replied to) I provided an > example of the ur-proposal as I understood it -- and it required > xsi:type everywhere. Matt: will you please correct my example and > post it back to > the list. > > > -----Original Message----- > From: Matthew Gertner [mailto:matthew.gertner@acepoint.cz] > Sent: Wednesday, February 05, 2003 8:45 AM > To: Burcham, Bill; Lisa-Aeon; UBL-NDR > Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in > instance > > > This isn't my understanding, or at least it is only one possible > interpretation. I would take it as a given that it is unacceptable to > require xsi:type on every element. This is hardly likely to encourage > adoption of UBL. > > Hence, UBL document types should reference UBL types/element in their > content models. If you want to use the ur-type of a type, you need to use > the ur-type of the document type as well. In this way you put the onus on > the ur-type users, which seems appropriate since they are likely to be the > minority. > > Matt > > -----Original Message----- > From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com] > Sent: Wednesday, February 05, 2003 3:40 PM > To: 'Lisa-Aeon'; UBL-NDR > Subject: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in > instance > > One issue with ur-proposal that was not discussed was this issue (from a > private message I produced on Monday -- also, see the attachment): > > ... I worked out a little example of the ur-type proposal a while back. I > think I've forwarded it before, but to save you groveling about the list > I've attached it again. I've made a namespace for ur-types and a dervied > one > for "UBL types". Then I made a third for a "third-party-restriction". A > key > issue we identified with Paella is as far as I can tell, still an issue > with > the latest ur-type proposal. If you look at a "vanilla" UBL instance > document (ubl-doc.xml) you see it has to use xsi:type on every element. > The > same holds for a "customized" UBL instance document > (third-party-restriction-doc.xml). > The reason this happens is that every element declaration must be of an > ur-type -- never a (derived) UBL type, or a (derived) customized type. It > must be so since this is the means by which we are able, after the fact, > to > derive from the ur-type without the horrendous "cascade" back through all > the referenceing content models (and the ones that reference those, and so > on -- remember Barcelona). The fact that the instance documents must carry > xsi:type everywhere means that schema validation is _not_ (on its own) > enforcing a particular vocabulary -- I can really use an ur-type wherever > I > want to and the schema validator isn't going to squawk. > If that's the case, then what, exactly is the value of the UBL namespace > (i.e. the non-ur-types)? I mean, should we just ship the "everything is > optional" ur-types and be done? Maybe I misunderstand the proposal. If so, > could someone please correct my simple example and show me some new > instance documents that don't require xsi:type everywhere? Barring > that we should > probably revisit our discussion from last March and decide whether that's > ok, or whether we need to fix it somehow (and no, I don't have any ideas > just now :-) One thing I have tried is to get the xsi:type attributes on > the > elements in ubl.xsd to _default_ to the UBL types somehow... But I fear I > am > not nearly the XSD wizard for that task -- heck I can hardly even describe > it. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC