ubl-ndrsc — archive

[Eve Maler]

 MHonArc v2.5.2 -->

















ubl-ndrsc message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: Re: [ubl-ndrsc] Restrictions of BBIEs




From: "Eve L. Maler" <eve.maler@sun.com>
To: "UBL Design Rules (E-mail)" <ubl-ndrsc@lists.oasis-open.org>
Date: Mon, 04 Nov 2002 12:41:30 -0500






There are a number of questions we need to ask:

- Should the UBL Library restrict the XSD simple types that underlie its 
BBIEs?  I assume the answer is "yes", otherwise we wouldn't have been 
interested in facet data in the spreadsheet.  (Right??)

- How should the UBL Library restrict these XSD datatypes?  Since I 
believe the simple types aren't directly bound to the content of a 
BBIE-related element but rather are applied as simpleContent when an 
element gets bound to a complex type, this gets complicated.  We've been 
assuming you can just bind ElementFoo to some CCTType and be done.  It 
may make more sense to build up the supplementary-component attributes 
into named groups, and reference them each time, along with associating 
the content of the element with the simple type directly.  Then we have 
a choice as to how to do the restriction: named and referenced vs. 
anonymous and in-place.  I suspect that named is better, along the lines 
of our "Garden of Eden" reusability approach so far.

(I'm sorry I don't have time to sketch examples of these possibilities, 
but I bet Gunther could do it easily...)

	Eve

Stuhec, Gunther wrote:
> Hello Mark,
> 
> one example:
> 
> I have BCC named "Article. Identifier". This "Identifier" do not have any restrictions. But sometimes, I will use this "Article. Identifier" for an EAN.UCC-13 with a fixed length of 13 digits. Therefore, it will be an advantage to restrict the length of the derived BIE like:
> 
> EAN-13. Article. Identifier
> 	length= 13
> 
> Kind regards,
> 
> 	Gunther
> 
> 
>