Re: [ubl-ndrsc] [QA Team] Review of XSD for Release

["Eve L. Maler" <eve.maler@sun.com>]

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