Re: [ubl] Agenda for Pacific UBL TC call 15|16 September 2008

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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