OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


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

-- 
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