[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] [QA Team] Review of XSD for Release
Sorry, but I don't understand this. All kinds of elements, both local and global, must be bound to types. When you do a restriction, you are restricting a type, not an element. You can do multiple restrictions of a type, leading to multiple derived types which you can use in whichever circumstances you wish. Let's say that, for whatever reason, both the <BasePriceDetails> element and the <ItemPriceDetails> element are bound to the type PriceDetailsType, which makes reference to the <PriceAmount> subelement: <complexType name="PriceDetailsType"> <sequence> <!-- optional element --> <element ref="PriceAmount" minOccurs="0"/> <!-- other stuff --> </sequence> </complexType> <element name="BasePriceDetails" type="PriceDetailsType"/> <element name="ItemPriceDetails" type="PriceDetailsType"/> If you (a customizer*) want to be able to restrict or even extend the content models for the two kinds of "details" elements, you can create two sibling derivations of PriceDetails (I know it's probably silly to eliminate <PriceAmount> from the second type, but it's just to show what you can do in a restriction): <!-- doing this from memory offline; syntax may be incorrect --> <complexType name="BasePriceDetailsType"> <restriction base="ubl:PriceDetailsType"> <sequence> <!-- make PriceAmount required --> <element ref="PriceAmount"/> </sequence> </restriction> </complexType> <complexType name="ItemPriceDetailsType"> <restriction base="ubl:PriceDetailsType"> <sequence> <!-- eliminate PriceAmount --> </sequence> </restriction> </complexType> Then in an instance, to get the two different effects you could use xsi:type (there are other ways to do this too, through substitution, but that's too complicated to show): <ubl:BasePriceDetails xsi:type="my:BasePriceDetailsType"> <ubl:PriceAmount>...</ubl:PriceAmount> </ubl:BasePriceDetails> <ubl:ItemPriceDetails xsi:type="my:ItemPriceDetailsType"> <!-- content with no PriceAmount in it --> </ubl:ItemPriceDetails> Now, if you want to restrict the *content* of <PriceAmount> in two different ways, and not just its *occurrence* in these two contexts, you can restrict/extend the type that *it* is bound to (in multiple ways, if you need to). So you would have instances of <PriceAmount xsi:type="my:PriceAmountType">. If all the elements in this picture were local instead of global, I think it becomes possible to *correlate* options at multiple hierarchy levels at once, because you are defining the element's characteristics directly inside the type rather than adding a level of indirection. But even when you're defining local elements inside a restriction of a type, those elements still have to adhere to the XSD rules for restriction, so your flexibility doesn't get appreciably bigger with local elements. Is there is a huge benefit to local elements in this situation that I'm just missing? Big enough to offset the value of having an element-based reusable vocabulary or to make it attractive to use local elements ourselves but still define global elements for the use of others? Eve * I'm assuming that we aren't doing any restrictions in the UBL Library ourselves. There's no data to support that in the spreadsheet, in any case. But on the other hand, we might want to have deeper type hierarchies in the UBL Library by virtue of creating additional object classes that have, as their "type" field, the name of another object class that they want to extend. So if the spreadsheet contained this (hey, shouldn't it be called PriceType according to our naming rules? oh well): (pink row) Price. Details type=PriceDetailsType (white row) PriceAmount 0..1 (pink row) Base Price. Details type=PriceDetailsType (white row) additional_element_A (pink row) Item Price. Details type=PriceDetailsType (white row) additional_element_B Then the perl script could turn this into a PriceDetailsType base type with PriceAmount in it, a BasePriceDetailsType extended from it with element A appended to the base content model, and an ItemPriceDetailsType extended from it with element B appended to the base content model. This depends on positive action from the LC SC, but even if they don't do it and the UBL Library keeps its flat hierarchy for now, it's still possible (as I demonstrate above) for customizers to get varying effects out of the same types. Lisa-Aeon wrote: > I spent time today going through this with Gunther, these are our thoughts: > > When you define a global element and define a restriction, that restriction > is inherited because you can not change the element name itself. > > If you have one global element called PriceAmount, and this PriceAmount is > used in both BasePriceDetails and ItemPriceDetails, then you can not > restrict the BasePriceDetails or ItemPriceDetails. If you do restrictions, > they are inherited into both Detail elements. > > If you want to do specific restrictions, and you want to use global elements > only, you have to change the name of the element itself. So, you would > change PriceAmount to something else. And this is not compliant with your > Dictionary Name rules or for our UBL tag name rules. > > For example you change the name PriceAmount to BasePricePriceAmount, then > you have big overlap and duplication in the names. This is not following > our UBL rules. > > Lisa and Gunther -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Technologies and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC