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-10-03 00:34 -0700, jon.bosak@sun.com wrote:
>Sorry to revisit this.  Two sets of questions:

I've answered them as I understand the situations, but Tim should 
confirm my answers.

>/==================================================================
>[Ken:]
>| >>(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"
>| >>
>[Tim:]
>| >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.
>[Ken:]
>|
>| 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.
>\==================================================================
>
>1. Does leaving J11 "as it is" mean that F11 and G11 stay
>    unchanged, too?

No it does not.  I believe F11 and G11 still have to be changed.  It 
was my analysis that was incorrect, not the corrections.  I suggested 
in my analysis that J11 should be empty and that is not 
appropriate.  The changes to F11 and G11 still apply.

>2. Does Ken's note about the schemas still apply?  (Change
>    "Despatch Advice. Document Status. Code" in the schema(s) to
>    "Despatch Advice. Document Status Code. Code")

I believe it does, as Tim's prose states "... the thing called 
Despatch Advice. Document Status Code. Code uses ...".

>/==================================================================
>[Ken:]
>| >>(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"
>| >>
>[Tim:]
>| >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.
>[Ken:]
>| Where the spreadsheet has "Reminder. Reminder Sequence Numeric.
>| Numeric" the XSD has "Reminder. Reminder Sequence. Numeric".
>|
>| I think the XSD is correct.
>\==================================================================
>
>But if the spreadsheet is correct as is, the XSD matches it, yes?

Tim's response of "no changes" would indicate that the original DEN 
is acceptable and does not change.  Since the XSD has the original 
DEN, then I think nothing happens to the XSD for this entry.

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


--
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]