[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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