UBL Transportation SC

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

    Posted 02-14-2011 18:17
    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: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


  • 2.  Re: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010

    Posted 02-14-2011 19:11
    Hello Andrew and TSC, I agree we should avoid changing the meaning of information items. About Locations expressed as a polygon I found that the "Google Earth" tool has a similar concept but it is not strictly a way to express a location, instead seems to be just a tool to highlight an area of interest. According to the GPS world there is an alternate location called "GPS Area". So "GPS Area" can be an alternate name for the new LocationRegion ABIE. At this point I ask you if circular areas have to be considered as well (this question is for who has raised the original issue) Cheers, Roberto > 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-AllDocum > ents-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-AllDocum > ents-2.1.html#t-CommonLibrary-41 > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-2.1.html#t-CommonLibrary-1083 > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-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-AllDocum > ents-2.1.html#Table_Address.Details > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-2.1.html#Table_Location.Details > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-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 > > -- * JAVEST by Roberto Cisternino * * Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor Roberto Cisternino mobile: +39 328 2148123 skype: roberto.cisternino.ubl-itlsc [UBL Technical Committee] http://www.oasis-open.org/committees/ubl [UBL Online Community] http://ubl.xml.org [UBL International Conferences] http://www.ublconference.org [UBL Italian Localization Subcommittee] http://www.oasis-open.org/committees/ubl-itlsc [Iniziativa divulgativa UBL Italia] http://www.ubl-italia.org


  • 3.  RE: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010

    Posted 02-14-2011 19:33
    Title: Re: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010 Roberto, Thanks for your comment. The original thought was that the area could be some kind of polygon so maybe GPS Area might not work so well since it might imply a circular region with a center point and radius as BBIEs. Maybe that is what a GPS Area is, can you get us a definition from a GPS source? Regards, Andy     From: Roberto Cisternino [mailto:roberto@javest.com] Sent: Monday, February 14, 2011 2:10 PM To: Andrew Schoka Cc: ubl-tsc@lists.oasis-open.org; 'Audun Vennesland'; 'Tim McGrath'; michael.onder@dot.gov; 'Jan Tore Pedersen'; 'Veile, Alan'; ken.holman@documentengineeringservices.com Subject: Re: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010   Hello Andrew and TSC, I agree we should avoid changing the meaning of information items. About Locations expressed as a polygon I found that the "Google Earth" tool has a similar concept but it is not strictly a way to express a location, instead seems to be just a tool to highlight an area of interest. According to the GPS world there is an alternate location called "GPS Area". So "GPS Area" can be an alternate name for the new LocationRegion ABIE. At this point I ask you if circular areas have to be considered as well (this question is for who has raised the original issue) Cheers, Roberto > 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-AllDocum > ents-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-AllDocum > ents-2.1.html#t-CommonLibrary-41 > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-2.1.html#t-CommonLibrary-1083 > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-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-AllDocum > ents-2.1.html#Table_Address.Details > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-2.1.html#Table_Location.Details > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum > ents-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 > > -- * JAVEST by Roberto Cisternino * * Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor   Roberto Cisternino   mobile: +39 328 2148123   skype:  roberto.cisternino.ubl-itlsc [UBL Technical Committee]     http://www.oasis-open.org/committees/ubl [UBL Online Community]     http://ubl.xml.org [UBL International Conferences]     http://www.ublconference.org [UBL Italian Localization Subcommittee]     http://www.oasis-open.org/committees/ubl-itlsc [Iniziativa divulgativa UBL Italia]     http://www.ubl-italia.org No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3443 - Release Date: 02/14/11


  • 4.  Re: RE: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010

    Posted 02-15-2011 20:03
    Hi Andrew, I did not asserted thet GPS Area circular, it was just a question I put to myself, but now I have a more clear idea. First I provide a good definition for understanding GPS measures and how they are used as locations or other uses on GIS or other applications. "GIS (Geographic Information Systems) is tool to display and analyze information geographically. GPS (Global Positioning Systems) is a technology that uses satellites to give one its position on the Earth with the aid of a GPS device or unit. GPS can be incorporated into GIS by using a GPS device to collect points, lines, or polygons, which can be imported into a GIS application for future analysis and interpretation." So I note GPS instruments can just provide single location (I verified this with an expert), then lines and polygons are used as a collection of points to describe something relevant for a GIS system. Cities are usually indicated with their centre (location), but a location could be even more precise (e.g. a building). Lines are used for distances. Polygons are usually used to associate other information (e.g. population density), but "Area" I think is a better term. The circular area is more related to the precision of a GPS that could be some meters. Finally I would see something like this for an Area: AreaCoordinate 0..1 (new ABIE) - AreaName 0..1 - AreaDescription 0..1 - LocationCoordinate 0..n (ASBIE) Cheers, Roberto > Roberto, > > Thanks for your comment. The original thought was that the area could be > some kind of polygon so maybe GPS Area might not work so well since it > might > imply a circular region with a center point and radius as BBIEs. Maybe > that > is what a GPS Area is, can you get us a definition from a GPS source? > > Regards, > > Andy > > > > > > _____ > > From: Roberto Cisternino [ mailto:roberto@javest.com ] > Sent: Monday, February 14, 2011 2:10 PM > To: Andrew Schoka > Cc: ubl-tsc@lists.oasis-open.org; 'Audun Vennesland'; 'Tim McGrath'; > michael.onder@dot.gov; 'Jan Tore Pedersen'; 'Veile, Alan'; > ken.holman@documentengineeringservices.com > Subject: Re: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November > 2010 > > > > Hello Andrew and TSC, > > I agree we should avoid changing the meaning of information items. > > About Locations expressed as a polygon I found that the "Google Earth" > tool has a similar concept but it is not strictly a way to express a > location, instead seems to be just a tool to highlight an area of > interest. > > According to the GPS world there is an alternate location called "GPS > Area". > > So "GPS Area" can be an alternate name for the new LocationRegion ABIE. > > At this point I ask you if circular areas have to be considered as well > (this question is for who has raised the original issue) > > Cheers, > > Roberto > >> 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-AllDocum >> ents-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-AllDocum >> ents-2.1.html#t-CommonLibrary-41 >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-2.1.html#t-CommonLibrary-1083 >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-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-AllDocum >> ents-2.1.html#Table_Address.Details >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-2.1.html#Table_Location.Details >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-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 >> >> > > > -- > * JAVEST by Roberto Cisternino > * > * Document Engineering Services Ltd. - Alliance Member > * UBL Italian Localization SubCommittee (ITLSC), co-Chair > * UBL Online Community editorial board member (ubl.xml.org) > * Italian UBL Advisor > > Roberto Cisternino > > mobile: +39 328 2148123 > skype: roberto.cisternino.ubl-itlsc > > [UBL Technical Committee] > http://www.oasis-open.org/committees/ubl > > [UBL Online Community] > http://ubl.xml.org > > [UBL International Conferences] > http://www.ublconference.org > > [UBL Italian Localization Subcommittee] > http://www.oasis-open.org/committees/ubl-itlsc > > [Iniziativa divulgativa UBL Italia] > http://www.ubl-italia.org > > _____ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1435/3443 - Release Date: 02/14/11 > > -- * JAVEST by Roberto Cisternino * * Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor Roberto Cisternino mobile: +39 328 2148123 skype: roberto.cisternino.ubl-itlsc [UBL Technical Committee] http://www.oasis-open.org/committees/ubl [UBL Online Community] http://ubl.xml.org [UBL International Conferences] http://www.ublconference.org [UBL Italian Localization Subcommittee] http://www.oasis-open.org/committees/ubl-itlsc [Iniziativa divulgativa UBL Italia] http://www.ubl-italia.org


  • 5.  RE: RE: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010

    Posted 02-15-2011 20:42
    Title: Re: RE: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010 Roberto, Thank you for you input on this topic. I guess both TSC and PSC should have an opinion on this. Andy     From: Roberto Cisternino [mailto: roberto@javest.com ] Sent: Tuesday, February 15, 2011 3:02 PM To: Andrew Schoka Cc: roberto@javest.com ; ubl-tsc@lists.oasis-open.org; 'Audun Vennesland'; ' Tim McGrath '; michael.onder@dot.gov; 'Jan Tore Pedersen'; 'Veile, Alan'; ken.holman@documentengineeringservices.com Subject: Re: RE: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November 2010   Hi Andrew, I did not asserted thet GPS Area circular, it was just a question I put to myself, but now I have a more clear idea. First I provide a good definition for understanding GPS measures and how they are used as locations or other uses on GIS or other applications. "GIS (Geographic Information Systems) is tool to display and analyze information geographically. GPS (Global Positioning Systems) is a technology that uses satellites to give one its position on the Earth with the aid of a GPS device or unit. GPS can be incorporated into GIS by using a GPS device to collect points, lines, or polygons, which can be imported into a GIS application for future analysis and interpretation." So I note GPS instruments can just provide single location (I verified this with an expert), then lines and polygons are used as a collection of points to describe something relevant for a GIS system. Cities are usually indicated with their centre (location), but a location could be even more precise (e.g. a building). Lines are used for distances. Polygons are usually used to associate other information (e.g. population density), but "Area" I think is a better term. The circular area is more related to the precision of a GPS that could be some meters. Finally I would see something like this for an Area:     AreaCoordinate   0..1      (new ABIE)     - AreaName   0..1     - AreaDescription  0..1     - LocationCoordinate  0..n     (ASBIE) Cheers, Roberto > Roberto, > > Thanks for your comment. The original thought was that the area could be > some kind of polygon so maybe GPS Area might not work so well since it > might > imply a circular region with a center point and radius as BBIEs. Maybe > that > is what a GPS Area is, can you get us a definition from a GPS source? > > Regards, > > Andy > > > > > >   _____ > > From: Roberto Cisternino [ mailto:roberto@javest.com ] > Sent: Monday, February 14, 2011 2:10 PM > To: Andrew Schoka > Cc: ubl-tsc@lists.oasis-open.org; 'Audun Vennesland'; ' Tim McGrath '; > michael.onder@dot.gov; 'Jan Tore Pedersen'; 'Veile, Alan'; > ken.holman@documentengineeringservices.com > Subject: Re: [ubl-tsc] FW: [ubl-psc] Status of issues raised in November > 2010 > > > > Hello Andrew and TSC, > > I agree we should avoid changing the meaning of information items. > > About Locations expressed as a polygon I found that the "Google Earth" > tool has a similar concept but it is not strictly a way to express a > location, instead seems to be just a tool to highlight an area of > interest. > > According to the GPS world there is an alternate location called "GPS > Area". > > So "GPS Area" can be an alternate name for the new LocationRegion ABIE. > > At this point I ask you if circular areas have to be considered as well > (this question is for who has raised the original issue) > > Cheers, > > Roberto > >> 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-AllDocum >> ents-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-AllDocum >> ents-2.1.html#t-CommonLibrary-41 >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-2.1.html#t-CommonLibrary-1083 >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-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-AllDocum >> ents-2.1.html#Table_Address.Details >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-2.1.html#Table_Location.Details >> > http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocum >> ents-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 >> >> > > > -- > * JAVEST by Roberto Cisternino > * > * Document Engineering Services Ltd. - Alliance Member > * UBL Italian Localization SubCommittee (ITLSC), co-Chair > * UBL Online Community editorial board member (ubl.xml.org) > * Italian UBL Advisor > >   Roberto Cisternino > >   mobile: +39 328 2148123 >   skype:  roberto.cisternino.ubl-itlsc > > [UBL Technical Committee] >     http://www.oasis-open.org/committees/ubl > > [UBL Online Community] >     http://ubl.xml.org > > [UBL International Conferences] >     http://www.ublconference.org > > [UBL Italian Localization Subcommittee] >     http://www.oasis-open.org/committees/ubl-itlsc > > [Iniziativa divulgativa UBL Italia] >     http://www.ubl-italia.org > >   _____ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1435/3443 - Release Date: 02/14/11 > > -- * JAVEST by Roberto Cisternino * * Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor   Roberto Cisternino   mobile: +39 328 2148123   skype:  roberto.cisternino.ubl-itlsc [UBL Technical Committee]     http://www.oasis-open.org/committees/ubl [UBL Online Community]     http://ubl.xml.org [UBL International Conferences]     http://www.ublconference.org [UBL Italian Localization Subcommittee]     http://www.oasis-open.org/committees/ubl-itlsc [Iniziativa divulgativa UBL Italia]     http://www.ubl-italia.org --------------------------------------------------------------------- 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/3445 - Release Date: 02/15/11