[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Agenda for Pacific UBL TC call 15|16 September 2008
I attempted to send my answers below directly to the NDR editors but I'm travelling and the hotel SMTP service is refusing to send the message to all recipients (including Jon). My comments will be repeated for those who could receive the previous transmission. Hopefully this message will be successfully transmitted to the mail list. At 2008-09-14 19:29 -0400, Jon Bosak wrote: >NAMING AND DESIGN RULES > > There are several questions that need to be answered before we > can complete this editing cycle. > > 1. Regarding this leftover issue from NDR 2.0: > > http://lists.oasis-open.org/archives/ubl/200803/msg00001.html > > - Do these code list metadata items belong in Section 6 on > code lists (as Ken has suggested) or among the instance > constraints in section 8? I think definitely section 6 on code lists. These are verifiable in schema-speak and need not be "supplemental" as instance constraints. My recollection of instance constraints were constraints not expressed using schema-speak. > - Are these new NDR rules? If so, I will need to assign > either CDLx or INDx identifiers, depending on the answer > to the first question. I see these not as rules per se but more as exposing what is already there as a byproduct of UN/CEFACT having expressed the core component types as W3C Schema data types. Back when I thought the NDR were guidelines for others to implement their own NDRs for their own schemas, and not just an exposition of the rules we followed for our own schemas, I saw exposing these as important because they were not really self-evident. They were, of course, if you looked in at the actual declarations, but most people reading the NDRs would probably find this useful to know. There was a section in the old NDR on code lists and if I recalled correctly there was a "guideline" regarding meta data. But there isn't really a "guideline" in version 2 because the UN/CEFACT schemas were written one way and one way only so all you can do is follow the schemas. When I examined what was distinct about the UN/CEFACT data types for code lists and identifiers I saw these instance-level meta data constructs as something that users should be aware of. And I also saw how inconsistent they were. Surely if someone were going to create their own NDR I would hope they would think of this area for their own code list and identifier constructs. If nothing else then hopefully they would come up with something far more consistent than the patchwork created by UN/CEFACT. So I think this section serves an important role. But I'm not sure I would call it a "rule" per se ... I think all of our rules are built on top of having chosen the UN/CEFACT data types for core components. I don't think any of the rules are actually *about* the UN/CEFACT data types ... only how to use them. > 2. Regarding this tracking item (minutes of Pacific call 1 July > 2008): > > /============================================================= > | Regarding NDR and order of BBIEs in advance of ASBIEs: this > | is not a rule, just a pattern. > | > | TM: This is a modeling policy established in order to > | maintain a logical sequence as items are added in subsequent > | revisions (so that we are not simply adding everything new > | at the end). The schema should express the logical sequence > | of the model. > | > | AGREED to add an editorial note to this effect in the NDR > | document. > \============================================================= > > I'm not clear on why exactly we need to say this Because it was an unexpressed rule regarding schema generation when reading the models. Or, if the schema generation is simply "express the model in the order of constraints found in the model", then it was an unexpressed rule when creating the stylesheets expressing the contents of the models. And I think it needs to be explicitly expressed somewhere. >and where > it would go. The relevant section in the NDR draft is 3.1, > Overall Schema Structure, and the only rule is, > > [GXS1]Except in the case of extension, where the "UBL > Extensions" element is used, UBL schemas SHOULD conform > to the following physical layout as applicable: > > It's in the figure that follows that the order of ABIEs and > BBIEs is given. Seems to me that the "SHOULD" in the rule > covers what we want to say here; is there something I'm > missing? Ah ... I see the "physical layout" referred to in GXS1 as the order of the declarations in the schema expressions, not the sequence order of elements declared in an aggregate: that being that an aggregate's BBIEs precede the aggregate's ASBIEs. The "rule" in UBL has been that an ABIEs constituent members are ordered with BBIEs followed by ASBIEs as is done in the spreadsheet expressions. I see this as one of two ways: The schemas follow the order of the spreadsheets and the spreadsheets are ordered accordingly, or the spreadsheets are ordered arbitrarily (and happen to be in the desired order) and there is an NDR rule that the order be guaranteed in the schema expression. I think the latter is the way to go ... make it a schema rule so that modelers who might wish to use an arbitrary order in the spreadsheets can do so. But I could be easily swayed the other way and make it a rule of the spreadsheet and express a new NDR rule that the spreadsheet order is preserved. > 3. Questions about several examples (text of each is given > at the end of this agenda). > > Example 1 > > - Wouldn't it make more sense if addresstype came first, > then address, then partytype? In UBL-CommonAggregateComponents-2.0.xsd all elements are listed first and then all types are listed afterward. Your cited example in your post does not match the order of things that I see in the actual schemas. I believe the examples in the NDR that show type and element declarations are merely reordering things to bring them into focus, rather than indicating the actual ordering used in the schema expressions. > - Are addresstype and partytype actually children of party? No, PostalAddress (of type AddressType) is a child of all Party elements (there are five of them), and PartyType describes the contents of the Party element. > - Where is the end tag for the party element? > > [Answer from BH: I think you are correct because the > NDR says that components should be an alphabetical > order - not 100% sure though.] Which party element? I do not see one in the excerpted "Example 1" of your post. > Example 2 > > - Is <xsd:complexType name="PartyType"> really supposed to > be *inside* party? > > [Answer from BH: It looks like the complexType is > outside the element declaration. However there isn't > a representation of xsd:annotation node. > > It would be better to modify: > > <xsd:element name="Party" type="PartyType"/> > > to: > > <xsd:element name="Party" type="PartyType"> > ... > </xsd:element> > ] I disagree. My understanding of W3C Schema is that you cannot simultaneously have type= and content for <xsd:element> ... it is one or the other, and the NDR requires all types to be global. Therefore, we are obliged to have <xsd:complexType> in order to declare the global type, and then we are obliged to use type= without children of <xsd:element> because the element uses a global type. > - Why are there no namespace prefixes on > "PartyIdentification", "PartyName", and "Address"? > > [Answer from BH: I think this is right because the > elements are being defined inside the CAC schema. If > the elements were being referenced, then they would > have the cac: namespace.] At the top of the schema is the declaration: targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" elementFormDefault="qualified" indicating that all unprefixed elements and types are qualified in the target namespace for CAC. > Example 3 > > - Is there a right angle bracket missing after > "BuyerPartyType" on the second line? The 2008-08-12 draft NDR that I'm looking at has an ellipsis, thus negating the need for a right angle bracket ... but, yes, since there are no other attributes I think it would be best to replace the ellipsis with a right angle bracket. Note there is *no* element in UBL called <BuyerParty> and no BuyerPartyType. While I recognize the NDR is only showing an example, perhaps an example of an actual element in UBL would be more apropos. Perhaps: <xsd:element name="SupplierParty" type="SupplierPartyType"/> I hope this helps. . . . . . . . . . . Ken -- Upcoming XSLT/XSL-FO hands-on courses: Wellington, NZ 2009-01 Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]