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

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

TSCers,

Most recently Audun raised this as an
update that didn’t make it into prd01. Now Ken has offered a different
option from just changing the cardinality of LocationCoordinate to 0..n, He is
asking for the opinion of others regarding the two options. Our last discussion
on this concluded that changing the cardinality would be sufficient but we hadn’t
considered this other option. Would others care to comment?

Regards,

Andy 

From: G. Ken Holman
[mailto:] 

Sent: Monday, February 14, 2011
11:11 AM

To: ''

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

 

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:

Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

No virus found in this message.

Checked by AVG - www.avg.com

Version: 10.0.1204 / Virus Database: 1435/3441 - Release Date: 02/13/11