[ubl-lcsc] Re: [ubl-ndrsc] XML Schema with Global Defined Elements.

[Tim McGrath <tmcgrath@portcomm.com.au>]

I am currently struggling with a), b) and c) - now that i relaise what 
they were talking about :-(

a) affects not only aggregates but also the basic elements within them. 
 ofr example, it is not just Address but also Address.Street, etc.. that 
need generic definition.

there are generic definitions in LC for Address.Street, but not for 
things like ID, Name, etc...(simple UBLNames that once relied on being 
within an aggregate.)

i need to resolve this today to keep with our release schedule.

Eve L. Maler wrote:

> Stuhec, Gunther wrote:
>
>> Hello all,
>>
>> I changed my Perl-Script now according the NDRSC definitions of 
>> Burlington. It generates all BIEs as global defined elements now. 
>> You'll find the complete package as an attached zip file.
>>
>> Due to problems with Tims Excel spreadsheet 
>> "UBL_Library_0p70_Reusable.xls", I still used the Excel spreadsheet 
>> "UBL_Reusable_04.xls". I renamed it in ""UBL_Reusable_05.xls", now.
>>
>> There are still some problems with global defined elements:
>> a.) Where I put the annotation of all BIEs? Within the complexType, 
>> or within each global defined element?
>
>
> I believe that the global element *declaration* should get pretty much 
> the same annotations as the complex type (aggregate BIE) that it is 
> bound to.  Since it's not yet a property of anything, its meaning is 
> incomplete.
>
> Each *reference* to a global element declaration should get the same 
> annotations that the local element declarations (association and basic 
> BIEs) were getting before.
>
> For example, in the good old example of Address appearing in two 
> different elements such as BuyerParty and ContactParty, the element 
> <Address> all by itself could only have a definition like "the 
> particulars that identify and locate the place where someone lives or 
> is situated, or where an organisation is situated."  (This is the real 
> definition for AddressDetails.)  But as soon as the element is used in 
> a parent context like BuyerParty, it now has a definition like 
> "associates (optionally) the party with one or more addresses".  (This 
> is the real definition for Buyer_Party.Address, but I actually think 
> it could be made more precise so that it refers to a buyer...)
>
>>
>> b.) Is it possible to put an annotation within an defined element, 
>> which refers to a global defined element?
>
>
> If you're asking whether it's possible to put an annotation in an 
> <element ref=>, I believe the answer is yes:
>
> http://www.w3.org/TR/xmlschema-1/#scIntro (Section 3.1.2)
>
>
>>
>> c.) There does not existing an global defined annotation of generic 
>> (reusable) BBIEs, which are defined as global defined elements. My 
>> perl script taking always the annotations from the last defined BBIE.
>
>
> Do you mean here that there is no spreadsheet entry for the BBIEs, and 
> therefore you don't know what the annotation content should be?  If 
> that's the case, perhaps the LC SC group can put together some entries 
> from CCTS text and put them in a spreadsheet for automatic usage.
>
>
>>
>> d.) There existing the tag name "PaymentTerms" twice. One for 
>> "Payment Terms. Details" and the other for "Payment Terms. Text". 
>> Both is correct, because we decided that we can eliminate the 
>> representation terms "Text" and "Details". I changed the 
>> "PaymentTerms" of "Payment Terms. Text" into 
>> "PaymentTermsPaymentTerms". But this looks not very nice. I guess, we 
>> will get this problem very often.
>
>
> We had discussed this problem in theoretical terms a long time ago, 
> but it's true that the local-element situation masked it.  I actually 
> think that it will be useful to resolve this somehow, because it would 
> have been really confusing to have two elements at completely 
> different structural levels with the same name.  Usually that's been a 
> no-no in the vocabularies I have developed in the past...
>
> As for a solution -- hmm.  Did you double-up the name in some 
> automatic fashion, or did you change it by hand?  It wouldn't be my 
> first choice to have a deterministic rule that depends on comparing a 
> name with all the other names that happen to be in the schema, but if 
> you have already done this in the perl script, that type of rule might 
> suffice for this release cycle.  Doubling the name doesn't seem to be 
> a really good choice, though; I'd prefer either 
> PaymentTermsDetails/PaymentTerms or PaymentTerms/PaymentTermsText.
>
> If you doubled the name by hand, and a temporary perl fix is not an 
> option, then it still comes down to the two choices I list above, only 
> done as proper naming rules.  We need to look at our rules about 
> eliding "Details" and "Text", and consider *not* eliding one of them.  
> I suspect that making the higher-level structural element longer (that 
> is, keeping "Details") is a better choice than keeping Text on all the 
> inner elements, because the latter would obscure the actual element 
> content more when you try to read an instance.
>
> For what it's worth,
>
>     Eve
>

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142