[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Second run in producing draft7 schemas
Michael and I have spoken together about these issues and i include my interpretation of the outcome below. Some of these issues indicate we may need a draft 8 of the models (see proposed new specialised data types model attached), so we shall be discussing this on the Tuesday Library Content call and I invite those with any input into this thread to join in. The details are: http://www.timeanddate.com/worldclock/fixedtime.html?year=2004&mon=03&day=09&hour=15&min=0&sec=0 ############################################# STANDING INFORMATION FOR UBL CONFERENCE CALLS U.S. domestic toll-free number: (866)839-8145 Int. access/caller paid number: (865)524-6352 Access code: 5705229 ############################################# Michael Dill wrote: >Dear all, >in order to have a good second run in producing schemas and to call them V1 >draft7, we have the following >questions and remarks: >--------------------- > >1. annotation for codes >The sent schemas do not yet have annotation/documentation for name and/or >description. We would prefer to get an example. Does Stephen has one? > Just to get things straight, when we say Code. Content we mean the content value for a code (for example, "USD" is a Code. Content in ISO4217 Alpha). When we say Code.Name we mean the meaning of Code. Content (for example, "American Dollars" is the Code. Name in ISO4217 Alpha associated with the Code.Content of "USD"). We agree that what is needed are Code.Content and Code.Name values for each of our 'standard' code lists. To get this started, please find attached ChannelCode.txt, a file that describes a set of these values for the communications channel code taken from UN/ECE 3155 (http://www.unece.org/trade/untdid/d03a/tred/tred3155.htm). This format replaces to old flat file format as we now need to define two elements. We need to do this exercise for each of the other standard codes in 1.0. However, the good news is that following are cases where Code. Content = Code. Name (because they are not real codes). ChipCode.txt DocumentStatusCode.txt LatitudeDirectionCode.txt LongitudeDirectionCode.txt LineStatusCode.txt OrderAcknowledgementCode.txt (that is used by AcknowledgementResponseCode ) SubstitutionStatusCode.txt NB there is also a new file called OperatorCode.txt that we need to create for the new 'code' called OperatorCode. it contains the numeric operators (+,-,*,/). - these files just need re-formatting in the new structure. So this means the only codes we need to populate with Content and an original Name are... PaymentMeansTypeCode.txt (taken from http://www.unece.org/trade/untdid/d03a/tred/tred4461.htm) CountryIdentificationCode.txt (taken from http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1-semic.txt ) AllowanceChargeReasonCode.txt (taken from http://www.unece.org/trade/untdid/d03a/tred/tred4465.htm ) CurrencyCode.txt (taken from http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc) Sue has agreed to look at these if she has time this week - but if anyone else can help out please advise a.s.a.p. > > >2. Unique Identifier >Please be aware that the spreadsheets do not have a unique identifier as >requested by NDR [DOC4]:" The xsd:annotationDocumentation element for every >Basic Business Information Entity repres definition there must be MUST >contain a structured set of annotations in the following patterns: § Unique >Identifier (mandatory): The identifier that references a Basic Business >Information Entity instance in a unique and unambiguous way." >Solution proposal: Either Tim asks Mark to change the NDR or somebody has to >define all UIDs. > we are well aware of this. it was one of my comments on the NDR document. The latest NDR document I have (draft n - dated 24th Feb.) still has this in. i have not seen any disposition as to why it remains in the NDR. it was long ago decided in LC that any form of UID in the library would be unnecessary and unmanagable. the Dictionary Entry Name is the one and only unique key. either we take this interpretation and duplicate the DEN as the Unique Identifier or we drop this. we do not want to create UIDs. perhaps someone in NDR can explain what else to do with this. > >3. CoreComponentParameter.XSD >What did we do regarding the DOC-Annotations : We JUST produce >annotation/documentation as in 1.0 Beta. It seems that this schema does not >contain the structures as required by NDR. Anne,is a check whether DOCxx is >implemented or not, an TTSC issue?. > this schema needs to be updated to reflect only what is actually used in the new models - in fact it should be generated from the meta data in the models. > >4. >Sue: Please help me to find codes and their names, please!!! Also, I'd >appreciate your check of the entries of the >UBL-UnSpecialisedDataTypes-draft7.xls. Maybe some entries are not correct >(rather CEFACT codelists than UBL). >Tim: IF you refer from specialisedDT to codelistsxx.TXT for NAMES of a code, >THEN: is this just a logical reference or more? if more then we have a >further codelist, don't we? > Michael and I have agreed that the codelistxx.TXT file must be the one and only definitive set of values for each specialised data type of a 'standard' code list. it is a physical reference. if we wanted to use another set of values then we would have to define another specialised data type for the code and use another codelistxx.TXT file. it does not matter what the file is called, becasue it is the association in the model says "this is the file that contains all the values in this list". however, we have tried to keep a filenaming convention using the CodeListName but this is just an internal UBL convention (becasue we probably wont want two specialised data types for one code list) . The schemas should not contain this filename, implementators need not see it. it's use is for the generation of schemas only. that is, it is an internal reference in the models because it is too hard to list these things in the spreadsheet with the other data. > >5. Tim, The next run will contain the UBL-CoreComponentTypes-draft7.xls. >However, Tim, the rules for built-in-types are (should, because I haven't >got any NDR update) in NDR, i.e. we cannot express everything here. > We agreed that in some cases the definitions for CCT/UDT and SDT may need to state some rules and constraints not able to be expressed in the model or the schema. e.g. do not use DateTime. Format. Text as the DateTime. Content is an xsd:dateTime value. > >6. Tim, a specialised Data Type "4461_ Code. Type" results in "_4461....", >because a XML tag must not begin with a digit. Are we aware of this? > no, i was not aware. thank you for pointing this out. i propose we prefix the code number with the agency. so 3155_ Code. Type becomes UN3155_Code. Type. things brings it into line with what we have already done for the ISO codes and keeps the first character alphabetic. this would indicate we need to change the CodeListID and therefore the specialised datatype names for some code lists - another action item for draft 8 of the models. > >7a) Tim, I understand that the next schema run produces draft7. Without any >version number? I think we will have to produce them more than once with the >same data (bugs, other changes) > we will use deltas for different schema generations from one version of models. so the first set of schemas from draft 7 models will be 7-1 and the next 7-2. >7b)To whom shall we send the schemas? > a copy will be sent to Anne Hendry (as co-chair of TTSC) to post to the TTSC site for publishing to all UBL members. A notice will then go out pointing everyone to this link. The TTSC should be gatekeepers of the generated schemas. >7c) I think that the Specialised... spreadsheet must have the codelist >namespace prefix at least or we do not have the necessary information to >produce schemas. Your opinion? > there are a few components of metadata that were in the original code list catalog and not in the code core component type. we could add these as UBL defined supplementary components to our specialised data types for codes. The ones i would suggegt are... Code List. Namespace Prefix. Identifier with UBLName of CodeListNamespacePrefixID (that is... codeListNamespacePrefixID) Code List. Description. Text with UBLName of CodeListDescription (that is... codeListDescription) Code List. Credits. Text with UBLName of CodeListCredits (that is... codeListCredits) If we agree this is permissable then it would mean we need to go to version 8 of the models. We can discuss this on tomorrow's LC call. > >8. Michael, Lisa: have you checked the schema sent by David for technical >correctness? It would be good to get any feedback ASAP, even if we still >have to amend them. > >9. Tim,you wrote: >"the code list mechanism used here is not what i expected to see. for >example, in Order we use the Data Type "ISO4217 Alpha_ Code. Type" for >the BBIE called "Order. Transaction Currency. Code". you have also >taken "ISO4217 Alpha" as a Qualifier for the Representation Term and >thereby changed the Dictionary Entry Name - we don't want to do this." >Hm, three sentences and three related,but different issues. >1. Do you talk about the following part of the schema? ><xsd:element name="TransactionCurrencyCode" type="sdt:ISO4217AlphaCodeType" >minOccurs="0" maxOccurs="1"> ><xsd:annotation> ><xsd:documentation> > <ccts:Component> > <ccts:CategoryCode>BBIE</ccts:CategoryCode> > <ccts:DictionaryEntryName>Order. Transaction Currency. ISO4217 Alpha_ >Code</ccts:DictionaryEntryName> > <ccts:Definition>the default currency of the transaction, to be used for >Invoicing.</ccts:Definition> > <ccts:ObjectClass>Order</ccts:ObjectClass> > <ccts:PropertyTerm>Transaction Currency</ccts:PropertyTerm> > <ccts:QualifierRepresentationTerm>ISO4217 >Alpha</ccts:QualifierRepresentationTerm> > <ccts:RepresentationTerm>Code</ccts:RepresentationTerm> > <ccts:DataType>ISO4217 Alpha_ Code. Type</ccts:DataType> > </ccts:Component> > </xsd:documentation> > </xsd:annotation> > </xsd:element> > >2. In order to be fast, please do me the favour and change the example as >you feel, how it should look like. > > <xsd:element name="TransactionCurrencyCode" type="sdt:ISO4217AlphaCodeType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:CategoryCode>BBIE</ccts:CategoryCode> <ccts:DictionaryEntryName>Order. Transaction Currency. Code</ccts:DictionaryEntryName> <ccts:Definition>the default currency of the transaction, to be used for Invoicing.</ccts:Definition> <ccts:ObjectClass>Order</ccts:ObjectClass> <ccts:PropertyTerm>Transaction Currency</ccts:PropertyTerm> <ccts:RepresentationTerm>Code</ccts:RepresentationTerm> <ccts:DataType>ISO4217 Alpha_ Code. Type</ccts:DataType> </ccts:Component> </xsd:documentation> </xsd:annotation> </xsd:element> all is fine except the qualifer for representation term should not be there. >CCTS:[D14] The Dictionary Entry Name of a Data Type shall consist of a >Representation Term—preceded by Qualifier Term(s) as necessary —followed by >a dot, a space character, and the term Type. The space character shall >separate words in multi-word Qualifier Terms and Representation Terms. Each >Qualifier Term shall be followed by an underscore. To allow spell checking >of the words in the Dictionary Entry Name, a space character shall follow >the underscores after Qualifier Terms. > > the qualifier for the data type is not the qualifer for the representation term, so does not form part of the name. >10. Tim wrote "also, why do we still have a 'DerivedCodeType'? Shouldn't >the >SpecialisedDataType just refer to the namespace for the precise code >list. Is this just a legacy of the old code list mechanism (and hence >an unnecessary level of referencing) or does it add some value?" >Michael: Tim, we can have different Specialised dataTypes using the same >Codelist, escpecially when we have some customisation. E.G. Country code >will be sued by Ownership of a vessel and by an address. > > dervided code type was an artifact used hwen we did not use specialized data types - i think it served a similar pupose and is now redundany. the example "sdt:ISO4217AlphaCodeType" above should refer directly to the schema for IS04217AlphaCodes. >11. Tim wrote "finally, the structures you build in the Specialised Data >Types still use the old/incorrect attributes and xsd:datatypes. these >should now be taken from those in the models." >Michael: The Specialised Data Types 'inherit' or inherit the attributes and >xsd:datatypes from the CoreComponentTypes. After having implemented your >CoreComponentTypes-draft7.xls. these issues should be done also in >Specialised Data Types. > > excellent. (note we may be requiring additional supplemntary components in the specialised data types). >thanks >Michael > > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
<Code><Content>AA</Content><Name>Circuit switching</Name></Code> <Code><Content>AB</Content><Name>SITA</Name></Code> <Code><Content>AC</Content><Name>ARINC</Name></Code> <Code><Content>AD</Content><Name>AT&T mailbox</Name></Code> <Code><Content>AE</Content><Name>Peripheral device</Name></Code> <Code><Content>AF</Content><Name>U.S. Defense Switched Network</Name></Code> <Code><Content>AG</Content><Name>U.S. federal telecommunications system</Name></Code> <Code><Content>AH</Content><Name>World Wide Web</Name></Code> <Code><Content>AI</Content><Name>International calling country code</Name></Code> <Code><Content>AJ</Content><Name>Alternate telephone</Name></Code> <Code><Content>AK</Content><Name>Videotex number</Name></Code> <Code><Content>AL</Content><Name>Cellular phone</Name></Code> <Code><Content>AM</Content><Name>International telephone direct line</Name></Code> <Code><Content>AN</Content><Name>O.F.T.P. (ODETTE File Transfer Protocol)</Name></Code> <Code><Content>AO</Content><Name>Uniform Resource Location (URL)</Name></Code> <Code><Content>AP</Content><Name>Very High Frequency (VHF) radio telephone</Name></Code> <Code><Content>CA</Content><Name>Cable address</Name></Code> <Code><Content>EI</Content><Name>EDI transmission</Name></Code> <Code><Content>EM</Content><Name>Electronic mail</Name></Code> <Code><Content>EX</Content><Name>Extension</Name></Code> <Code><Content>FT</Content><Name>File transfer access method</Name></Code> <Code><Content>FX</Content><Name>Telefax</Name></Code> <Code><Content>GM</Content><Name>GEIS (General Electric Information Service) mailbox</Name></Code> <Code><Content>IE</Content><Name>IBM information exchange</Name></Code> <Code><Content>IM</Content><Name>Internal mail</Name></Code> <Code><Content>MA</Content><Name>Mail</Name></Code> <Code><Content>PB</Content><Name>Postbox number</Name></Code> <Code><Content>PS</Content><Name>Packet switching</Name></Code> <Code><Content>SW</Content><Name>S.W.I.F.T.</Name></Code> <Code><Content>TE</Content><Name>Telephone</Name></Code> <Code><Content>TG</Content><Name>Telegraph</Name></Code> <Code><Content>TL</Content><Name>Telex</Name></Code> <Code><Content>TM</Content><Name>Telemail</Name></Code> <Code><Content>TT</Content><Name>Teletext</Name></Code> <Code><Content>TX</Content><Name>TWX</Name></Code> <Code><Content>XF</Content><Name>X.400 address</Name></Code> <Code><Content>XG</Content><Name>Pager</Name></Code> <Code><Content>XH</Content><Name>International telephone switchboard</Name></Code> <Code><Content>XI</Content><Name>National telephone direct line</Name></Code> <Code><Content>XJ</Content><Name>National telephone switchboard</Name></Code>
UBL-SpecialisedDataTypes-draft8.xls
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]