Some PRD1 feedback

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

Fellow UBL TC members,

I'm not convinced I've remembered everything I thought of but didn't 
write down, but when trying to recall issues I've got these four items:

(1) The latest UN/CEFACT country list includes #189-SERBIA & MONTENEGRO:

    http://www.unece.org/cefact/recommendations/country.htm

... but the code list we are using in PRD1 is the one from 2006 and 
doesn't have this code.  I tripped over that one because of my 
training, but I wonder if there are other lists available for us to 
update for PRD1.

In PRD1 we have the following code lists:

AllowanceChargeReasonCode-2.1.gc
BinaryObjectMimeCode-2.1.gc
ChannelCode-2.1.gc
CurrencyCode-2.1.gc
PackagingTypeCode-2.1.gc
PaymentMeansCode-2.1.gc
TransportEquipmentTypeCode-2.1.gc
TransportModeCode-2.1.gc
UnitOfMeasureCode-2.1.gc

In 2006 we had the following code lists:

Those related to core component supplementary values (all have been 
updated above):

BinaryObjectMimeCode-2.0.gc
CurrencyCode-2.0.gc
UnitOfMeasureCode-2.0.gc

Those not related to core component supplementary values (only some 
have been updated above):

AllowanceChargeReasonCode-2.0.gc
ChannelCode-2.0.gc
ChipCode-2.0.gc
CountryIdentificationCode-2.0.gc
DocumentStatusCode-2.0.gc
LatitudeDirectionCode-2.0.gc
LineStatusCode-2.0.gc
LongitudeDirectionCode-2.0.gc
OperatorCode-2.0.gc
PackagingTypeCode-2.0.gc
PaymentMeansCode-2.0.gc
SubstitutionStatusCode-2.0.gc
TransportEquipmentTypeCode-2.0.gc
TransportModeCode-2.0.gc
TransportationStatusCode-2.0.gc

Can we make updated genericode files with the latest country code 
list and perhaps other lists not related to core component 
supplementary values?

(2) Regarding location coordinates, it was discussed back in March 
that we needed a cardinality of more than one in order to describe 
polygonal areas instead of only point areas:

At 2010-03-11 06:42 -0500, Jon Bosak wrote:
>MINUTES OF ATLANTIC UBL TC MEETING
>WEDNESDAY 10 MARCH 2010
>...
>    PLB: A single item was revised: the cardinality of Location
>    Coordinates was changed.  We should specify a BIE for Area, but
>    we can pick this up along with other changes following the
>    first public review.  The changes were made around noon on
>    Monday.

I'm looking at all of the ASBIEs for location coordinates and they 
all appear to be still 0..1 and not 0..n (but see note below in (4):

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-41
http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-1083
http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-1689

But, perhaps we shouldn't increase the cardinality of location 
coordinate because the collection of coordinates makes up a new 
semantic being a location region.  Since the region is a new semantic 
do we need a new "location region" ABIE and have two ASBIEs: the 
existing "location coordinate" for a point location and a new 
"location region" for an area location?  The "location region" would 
then contain one-or-more "location coordinate" elements.

Or, do we just have a community interpret a set of location 
coordinates to implicitly describe a region rather than a set of 
individual unrelated location coordinates?

I'm not the business expert, just the angle-bracket guy, so I don't 
know which of the two ways to proceed ... I just know *someone* asked 
us to describe an area and I don't think we have that in PRD1.

(3) Many description fields have non-Latin-1 characters in them, such 
as "smart quotes" (Unicode curly quote characters) for an 
example.  Of course Unicode characters are allowed in XML, and so 
there is nothing really *wrong* with those descriptions.  But some of 
my software tripped over the non-Latin-1 characters.  Others might be 
using the descriptions not expecting the full Unicode set to be 
used.  I suggest we tighten up our rules for descriptions not to 
allow all Unicode characters, but only Latin-1 characters.

If this is agreed, I can add a "model check" to my SGTG package to 
report those spreadsheet cells that include non-Latin-1 characters.

(4) I brought up earlier that there are many tautological 
definitions.  By this I mean a "definition" that defines nothing and 
only explains what is already obvious simply by the construct.

An example is the aforementioned location coordinate ASBIE in Address:

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-41

The definition is:   "An association to Location Coordinate."

This tells *nothing* new to the user they don't already know simply 
from the fact that it is an ASBIE and that the associated object 
class is location coordinate.

Thankfully, the second and third ASBIE elements cited above *do* have 
a definition that is slightly better:  "Information about physical 
(geographical) location."

Depending on the decision for (2) above, a better description might 
be  "A physical (geographical) location described by a point or a set 
of related points."  And even different if we decide to have both a 
location coordinate and a location region as separate ABIEs.

But there are *so* many of these tautological definitions.  When I 
walk through the model with someone new to UBL I would like them to 
tell me which elements they want by reading the definitions and 
knowing how the elements are expected to be used/interpreted.  What 
is happening now is I'm hand-holding them through the pruning process 
and we come up with a definition like "An association to Location 
Coordinate" and they ask "so what does that mean and do I need 
it?".  I can't answer them when I don't know *why* the construct is 
in the ABIE.  The definition should be telling me what it is 
semantically, not what it is syntactically.


(5) I'm on the hook for a revision to the prose sections related to 
the extension mechanism and the revised SGTG schema modules for PRD2.

(6) I'm on the hook for a revision to the digital signature 
methodology document from the Security SC for PRD2.

Please let me know if you have any questions or if you can think of 
anything else anyone is expecting from me for PRD2.  If there are 
other obligations from me, I can't recall them this evening and need 
to be prodded.

. . . . . . . . . . Ken

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal