Re: Model changes for Transport

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

Thanks for posting this, Andy!

I think the suggested changes for descriptions, extension, remarks, 
terms, etc. are all appropriate for the reason of including their 
equivalents in multiple languages.

At 2012-12-10 22:10 -0500, Andrew M Schoka wrote:
> Please review them at your earliest convenience and no later than 13 
> Dec 2012 so that the UBL TC can go forward with  the preparation of 
> UBL 2.1 PRD3.

DEN: Goods Item. Required_ Customs Identifier.Identifier
- if Jon's suggestion that there exists a single identifier for a set 
of tariff codes, then the cardinality shouldn't change
- if you have decided that "0..n" is appropriate for this, then the 
definition should revert closer to the original, though the original 
definition is in the plural and refers to a singleton concept that is 
repeatable
- original: Additional tariff codes required to specify a type of 
goods for Customs, transport, statistical, or other regulatory purposes.
- proposed: Additional tariff code required to specify a type of 
goods for Customs, transport, statistical, or other regulatory purposes.

DEN: Hazardous Item. Technical_ Name. Name
- in column H it is asked "Just one hazardous substance per goods 
item?" but that doesn't suggest that there exists more than one name 
for a single hazardous item
- a name is a property of a single hazardous item ... if you need 
more than one hazardous substance, this is not the place to use 
"0..n", it has to be at a level "higher" in the model by repeating 
the ASBIE to Hazardous Item
- proposed: keep cardinality 0..1 unless it is necessary to express 
more than one name for a given single hazardous item

DEN: Item. Origin_ Address
- this was already "0..n" in UBL 2.0 as "Item. Origin_ Address. Address"

DEN: Transport Equipment. Referenced_Consignment Identifier. Identifier
- this change shouldn't be based on language but on the possibility 
that a single instance of Transport Equipment needs multiple 
references to consignments ... is that true?

> Further,
> DEN of Status.Text has no UBL name (row 778 of Jon's TSC analysis. 
> Please remove entry

I am guessing this is an inadvertent corruption of the row in the 
spreadsheet because UBL2.1PRD2 includes a "Status. Text" construct:

http://docs.oasis-open.org/ubl/prd2-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-1738
http://docs.oasis-open.org/ubl/prd2-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#d-CommonLibrary-1746

> DEN  of SpecialTransportRequirements (row 813) has a misspelling in 
> the term Requirements. Correct spelling.

Well spotted.  But is this not also another candidate for 
"0..n"?  PRD2 has it as "0..1" and the definition certainly implies 
that it is a prose field.  And as a field for prose, it should 
accommodate multiple languages:

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

I don't see it in your list of suggested changes for "0..n".

I hope this helps.

. . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/o/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal