OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] Re: More typos in the IDD spreadsheets and UBL 2.0 spreadsheet models


At 2007-09-05 12:06 +0800, Tim McGrath wrote:
>As requested here are my comments on the typos Ken 
>identified.  Apart from one or two items, I am happy that these are 
>valid corrections.

As requested I've compared the DEN values of my suggested repairs 
against the DEN values found in the XSD files and I've found 6 
discrepancies where four look like repairs are needed to the XSD 
files (though these are documentary changes and do not affect 
schema-validity).  All 6 were touched upon in my earlier comments.

>>(9) - UBL 2.0 Common Library cell G424 reads "Criterion" and should 
>>read "Code" because the representation term is "Code", which then 
>>changes F424 from "Preference" to "Preference Criterion"
>>
>>
>Agreed

Where I had "Goods Item. Preference Criterion Code. Code" the XSD has 
"Goods Item. Preference Criterion. Code".

If I was correct in my change, then I think the XSD is incorrect and 
the DEN and other CCTS documentation components need to change to 
reflect the repairs in the spreadsheet.

>>(10) - UBL 2.0 Common Library cell G577 reads "Method" and should 
>>read "Code" because the representation term is "Code", which then 
>>changes F577 from "Inspection" to "Inspection Method"
>Agreed

Where I had "Line Item. Inspection Method Code. Code" the XSD has 
"Line Item. Inspection Method. Code".

If I was correct in my change, then I think the XSD is incorrect and 
the DEN and other CCTS documentation components need to change to 
reflect the repairs in the spreadsheet.

>>(14) - UBL 2.0 Common Library cell G815 reads "Accounting Cost" and 
>>should read "Text" because the representation term is "Text", which 
>>then changes F815 from empty to "Accounting Cost"
>>
>This is correct as it stands, or least it is the way we intended it 
>to be. In fact, the pair "accountingcostcode" and "accountingcost" 
>appear in many places and we debated this long and hard. The 
>representation term does not have to be the property term noun.  The 
>principle we are trying to maintain is that the entire property term 
>(plus the object class term) provides a description of the 
>item.  You should be able to understand what something is just by 
>these two things.  The representation term is not part of the 
>meaning of an item, it just denotes how that item is 
>represented.  So in many cases (especially with codes) the 
>representation term is repeated in the property term - because 
>knowing the representation helps distinguish things like "account 
>cost" as a code from "accounting cost" as text.  We tend not to use 
>"text" as a property term because it is generally assumed and would 
>make the names overloaded (it is the same reason we drop it from the 
>tag names).
>when you take this into consideration then it makes sense the way we 
>have it.  it looks odd, becasue the 'property term posessive noun' 
>(column F) is "accounting cost" when it is a code and yet it is the 
>'propoerty term primary noun' (column G) when it is a text 
>item.  The shift is caused by the inclusion of 'code' as the primary noun.

Where the spreadsheet has "Reminder Line. Accounting Cost Text. Text" 
while the XSD has "Reminder Line. Accounting Cost. Text".

I think the XSD is correct.

>>(15) - UBL 2.0 Common Library cell G856 reads "Level" and should 
>>read "Code" because the representation term is "Code", which then 
>>changes F856 from "Shipping Priority" to "Shipping Priority Level"
>>
>Agreed

Where I had "Shipment. Shipping Priority Level Code. Code" the XSD 
has "Shipment. Shipping Priority Level. Code".

If I was correct in my change, then I think the XSD is incorrect and 
the DEN and other CCTS documentation components need to change to 
reflect the repairs in the spreadsheet.

>>(23) in UBL-DespatchAdvice-2.0.ods cell J11 has "Document Status" 
>>and I think it should be empty because other codes have a data type 
>>of just "Code. Type" without being qualified, which also leads to 
>>F11 changing from "Document" to "Document Status" and G11 from 
>>"Status" to "Code"
>>
>There are two issues here and they are not related.  You are correct 
>in the second statement, (F11 changing from "Document" to "Document 
>Status" and G11 from "Status" to "Code") - this is in line similar 
>corrections as listed above.
>However, this is not related to the use of Data Type 
>Qualifiers.  Data Type Qualifiers are used to identify UBL defined 
>qualified data types that apply to this item.  In this case, the 
>thing called Despatch Advice. Document Status Code. Code uses the 
>set of values defined as Document Status_ Code. Type.  In fact, the 
>property term and data type qualifier term don't have to be 
>identical - but they often are (which makes sense).
>Where we don't have a specific values for a code, then the Data Type 
>Qualifier is not used.  This is the case for Despatch Advice. 
>Despatch Advice Type Code. Code.  We don't define these codes.
>So the first statement is not true.  We can leave J11 as it is.

Where the spreadsheet has "Despatch Advice. Document Status Code. 
Code" the XSD has "Despatch Advice. Document Status. Code".

If I was correct in my change, then I think the XSD is incorrect and 
the DEN and other CCTS documentation components need to change to 
reflect the repairs in the spreadsheet.

>>(25) in UBL-Reminder-2.0.ods cell F12 has "Reminder" and should be 
>>"Reminder Sequence", cell G12 has "Sequence" and should be 
>>"Numeric", and cell H12 has the hardwired string "Reminder 
>>Sequence" when it should be the formula in every other row of 
>>column 12 ... this then changes the DEN in B12 from "Reminder. 
>>Reminder Sequence. Numeric" to "Reminder. Reminder Sequence Numeric. Numeric"
>>
>The values are correct as they stand (although I agree the formula 
>should be used not the hardwired text). As mentioned above, the 
>representation term does not have to be in the property term.

Where the spreadsheet has "Reminder. Reminder Sequence Numeric. 
Numeric" the XSD has "Reminder. Reminder Sequence. Numeric".

I think the XSD is correct.

Other than those 6, the set of DENs found in 
CommonAggregateComponents XSD and document XSD files matches the set 
of DENs found in the massaged IDD spreadsheets.

So I think the XSD documentation of the DEN and other columns is 
incorrect in four places because the algorithm acted on invalid 
component cell values in the master spreadsheet.  None of these XSD 
changes will affect schema-validity of UBL instances.  I think the 
other two differences are repairs to the IDD DEN values.

Tim, can you confirm this please?

Thanks!

. . . . . . . . . . . . Ken

--
Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]