Re: [ubl-psc] Status of issues raised in November 2010

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

At 2011-02-14 16:41 +0100, Arianna Brutti wrote:
>Hi Ken,
>
>--> about item (2), currently we have:
>
>ASBIE from Location to LocationCoordinate cardinality 0..1
>
>and LocationCoordinate is as follows:
>
>CoordinateSystemCode                  0..1
>LatitudeDegreesMeasure                 0..1
>LatitudeMinutesMeasure                  0..1
>LatitudeDirectionCode                     0..1
>LongitudeDegreesMeasure              0..1
>LongitudeMinutesMeasure               0..1
>LongitudeDirectionCode                  0..1
>AltitudeMeasure                              0..1
>
>Please, let me know if the final decision was to update the cardinalities.

The decision is up to PSC, not to me.  Someone identified the need to 
express an address as an arbitrary area and could not do so using a 
single location coordinate.  I am not questioning the definition of a 
single location coordinate, I'm questioning its use in the address 
and other locations in the model.

In my argument I presented two possible ways of doing this:  simply 
changing the cardinality to "0..n" or by introducing a new ABIE for a 
LocationRegion (or LocationArea?) that represents a different 
semantic (area instead of point).  Then LocationCoordinate stays as 
"0..1" in address and the new LocationRegion is added to address as 
"0..1".  The other LocationCoordinate uses might also be other 
candidates for adding a LocationRegion.  Then the definition of 
LocationRegion has LocationCoordinate with "0..n" so that one then 
describes the region as a set of points.

But it is up to PSC to decide to change LocationCoordinate or 
introduce LocationRegion.  It is not up to me.

Looking at the LocationCoordinate ABIE here:

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_LocationCoordinate.Details

... I see by the carets below the UBL name that there are three 
ASBIEs that reference this ABIE:

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

By clicking on the caret below the row number at the left, these are 
the ABIEs where we would consider adding the new LocationRegion if we 
go that way; Address, Location and SubsidiaryLocation:

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Address.Details
http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Location.Details
http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_SubsidiaryLocation.Details

It is my opinion that we add LocationRegion rather than increasing 
the cardinality of LocationCoordinate because the two concepts are 
different, but they only need to be made different if this makes 
business sense.  No need making it unnecessarily complex if it is 
sufficient to simply increase the cardinality of 
LocationCoordinate.  You know I have a bad habit of making things 
more complex than necessary when I don't understand the business requirement.

I hope TSC will have an opinion about this, and so I will post to TSC 
a link to this discussion today.  I would think that in 
transportation this question of locations and regions is important.

>--> About point (3): could you provide me a list of "bad" descriptions?

Yes, I will.  I was unsure if this was as important to PSC as it is 
to me.  I would like to see all of the descriptions use only ASCII 
characters (Unicode characters from "~" and below).  This will help 
anyone who is working with the spreadsheets and schemas.

This report will be included in my SGTG analysis of the next export 
from eDoCreator.  If I get the time before the calls this week, I 
will try to run the report on PRD1.

Oh, I failed to mention that prohibiting "--" in definitions will 
also be helpful so that downstream XML processing tools don't have to 
change the definition when putting the definition into an XML comment.

>--> About point (4) I agree with you. During the 2nd public review, 
>we could make a list of tautological definitions and update them.

I'm glad both PSC and TSC will take on this task.  I think it is 
incredibly important in order to convey the meaning of what PSC/TSC 
has meant for each of the constructs.  This will reduce the number of 
support questions sent to the TC or to UBL-Dev as more and more 
people embrace UBL.

Thank you, Arianna.

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