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 spreadsheetmodels


I confirm Ken's understanding.

G. Ken Holman wrote:
> 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
>
>

-- 
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath




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