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