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