Re: [ubl-sbsc] Fwd: Codelist support for UBL SBS and UBL SBS XPath questions (Sacha)

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

At 2006-03-06 11:32 +0000, Stephen Green wrote:
>Sacha presents some interesting ideas for SBSC:
>should we seek to help small businesses by adding
>further code-related artifacts, e.g. to the SBS?

Sounds appropriate to me ... and I do it all from the schema 
expressions so there should be no problem mechanically creating what is needed.

> > From: Sacha Schlegel <sschlegel@cyclonecommerce.com>
> > To: Stephen Green <BRITSDG@bristol-city.gov.uk>
> > Date: Thu, 02 Mar 2006 04:21:02 -0700
> > Subject: Codelist support for UBL SBS and UBL SBS XPath questions
> > Hi Steve
> >
> > I just read the UBL-2 UBL-2-codelist-support-0.1.zip support file
> > package.

It has yet to be adopted by the TC but I am encouraged by the 
reception this proposal has received from UBL and other standards efforts.

> > o Will there be a codelist package for UBL-2 SBS or will the same
> > codelists be used for UBL-2 SBS?

Would you anticipate subsetting the sets of codes themselves, or just 
the selection of code lists?

My initial thought is that because SBS only subsets the 
already-available set of UBL information items then only the 
selection of code lists changes, thus changing only the code list 
context association file and the set of genericode files delivered.

Since my belief is that the SBS does not change any semantics of the 
information items, then the code list definitions (.gc genericode 
files) from UBL would be used unchanged in SBS (since their meaning 
hasn't changed).  The SBS default code list context association file 
used by trading partners would merely be a smaller file than used in 
UBL because of the fewer information items.

> > o In case there will be a specific one for UBL SBS, do you intend to
> > strip the codelists for SBS (eg remove codes that will not likely be
> > used by a Small Business)? Or would this go against a concept of code
> > lists?

I personally believe supplying only the subset of code lists of UBL 
that are relevant to the SBS, plus a replacement default code list 
context association file relevant to the SBS, would not go against 
concepts currently under discussion.

> > o When I was looking at the genericode instances I saw some (eg the
> > InvoiceTypeCodeType.gc) are still empty. Are they still empty because
> > they are currently populated (version 0.3 would indicate that it is work
> > in progress)?

They are empty because it is up to trading partners to decide which 
values to use, and no initial values are supplied by the UBL 
TC.  Note, however, that Tony indicated my improper interpretation of 
an "undefined code list" semantic in the structure of genericode 
files, thus the syntax of these empty code list sets I provide in 
draft 0.4 will need to change.  With much appreciation to Tony, he is 
undertaking to clarify the genericode expression of an undefined set 
of coded values.

At 2006-03-01 11:11 -0800, jon.bosak@sun.com wrote:
>MINUTES OF ATLANTIC UBL TC MEETING
>...
>       TonyC: Added metadata and a change to allow empty code lists
>       having only metadata.  Will deliver the week of 3 April.

For the information items in UBL 1.0 defined by enumerations, there 
are genericode instances populated with the enumeration values that 
trading partners can use as initial values when negotiating the set 
of values upon which they agree.

The UBL TC can choose to define default sets of codes for other lists 
if it wishes, as we are not constrained to only use enumerations from 
UBL 1.0 ... that was just the starting point to which nothing has yet 
been added.

> > From: Sacha Schlegel <sschlegel@cyclonecommerce.com>
>...
> > UBL SBS XPath questions:
> >
> > Question 1)
> >
> > Regarding the Invoice-XPath.txt file:
> >
> > 15 indicates that there must be a CreditorSupplierParty element
> > 18 indicates that there must not be a Party element
> > 20 indicates that there must be a Name element

Information item 18 indicates there *may* not be a Party element as 
the cardinality is optional.

> > In the XML schema Name is a child element of Party which is a child
> > element of CreditorSupplierParty

Yes, the schema dictates the document hierarchy of these information items.

> > actual question:
> >
> > o Does 20 indicate that there must be a Name element only if there is a
> > Party element

Indeed.

> > o If true could this result in an empty but valid CreditorSupplierParty
> > element?

That *is* what the UBL-CommonAggregateComponents-2.xsd schema says:

   <xsd:complexType name="SupplierPartyType">
     <xsd:annotation>
       ...
     </xsd:annotation>
     <xsd:sequence>
       <xsd:element ref="cbc:CustomerAssignedAccountID" minOccurs="0" 
maxOccurs="1">
         <xsd:annotation>
           ...
         </xsd:annotation>
       </xsd:element>
       <xsd:element ref="cbc:SupplierAssignedAccountID" minOccurs="0" 
maxOccurs="1">
         <xsd:annotation>
           ...
         </xsd:annotation>
       </xsd:element>
       <xsd:element ref="Party" minOccurs="0" maxOccurs="1">
         <xsd:annotation>
           ...
         </xsd:annotation>
       </xsd:element>
     </xsd:sequence>
   </xsd:complexType>

> > Question 2)
> >
> > o What is the reason to have omitted the datatypes in the XPath.txt (eg
> > Invoice-XPath.txt) files? Wouldn't that be another valuable information
> > item maybe as a forth column? I assume there are reason the datatype
> > information is not present in the XPath text file.

Merely brevity ... the Invoice-XPath.xml contains type information:

   <Element name="CreditorSupplierParty" type="SupplierPartyType" ...
      <Element name="CustomerAssignedAccountID" 
type="CustomerAssignedAccountIDType" ...

The supplied xpath.xsl sample stylesheet could easily be modified to 
expose the type information in a custom report if you need to see it 
in a text summary.

I hope this helps ... thanks for the feedback and questions, Sacha!

. . . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal