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