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:gkholman@CraneSoftwrights.com]
Sent: Monday, February 14, 2011
11:11 AM
To: 'ubl-psc@lists.oasis-open.org'
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:gkholman@CraneSoftwrights.com
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