OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ssc message

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


Subject: Re: [ubl-ssc] question on open alignment issues


Hi Sylvia,

Yes, this email was referring to the 1.0 issues list.  I went back and 
looked at the last version of the issues list (published with the OASIS 
spec - http://lists.oasis-open.org/archives/ubl/200409/msg00035.html ) 
and the disposition was to change the order in the schemas (not the 
ss).  It notes that this was done, as per David, on 22 July, becuase it 
was in Stephen's 'to fix in schemas' list that he sent to David.  That 
list is attached.  So I can't quite tell - are you saying now that 
number b.1 was not done?  In looking at the schemas I see that the Code 
attrs are in ccts table 8-1 order, but I do see that one of the attrs 
for Identifier is not in ccts talble 8-1 order.

It would be good to clarify the current state of the schemas w.r.t. this 
issue, because I think at the last F2F Tim agreed to chaange the order 
of the attrs in the ss, so if he does make that change and the schemas 
are not in sync, then this is for naught (and I'm not sure, based on 
logic and Mark's comment that this is a path we want to go down anyway).

I brought up the question because I noted that in Michael's original 
issue submission he only talked about these two types, but in further 
investigation I found another that was not in ccts table 8-1 order (as 
noted in my original email below), so now I'm really wondering what 
we're doing.  I'd like to clarify this by asking the following 
questions, which can probably only be answered by Michael, David, and/or 
Stephen, Mark, Tim:

1. For what reason would we want to strive to represent the schema 
attributes in an order similar to CCTS 2.01?
2. For what reason would we want to strive to represent the ss 
attributes in an order similar to the schems, or to CCTS 2.01?
3. When you say, Michael, they are not as in CCTS 2.01, are you talking 
about  CCTS 2.01 table 8-1?  Because in CCTS 2.01 table 8-2, which lists 
all the ccts approved components, they are in a different order.
4. If we are to agree (again) that this is important (at least for the 
schemas), who will volunteer to look at *all* of these types again in 
the current schemas and make sure we are compliant with this request 
(because obviously the first list submitted with the issue was incomplete)?
5. Do we need a rule for this?

I'm hoping that issue related to maintaining some order relative to CCTS 
as the spec moves forward will be addressed in the discussion of answers 
to questions 1 and 2.

Let's try to get this nailed down now so we don't have to revisit.  
Since this was originally Michael's issue, perhaps he can answer the 
first couple of questions (sorry if this is a request for info already 
given originally, but I don't think the main reasoning has been 
adequately captured or conveyed - it's not in the issues list at least, 
which just notes a difference, but not why this is a problem).

I'm cc-ing the main ubl list because this involves more than just ssc.

-A

Sylvia Webb wrote:

>Anne,
>
>I'm copying a email message from Michael about this issue.  It appears that
>this may have been approved but it was not clear therefore we did not make
>the change.
>
>Start of Michael's original email:
>"Anne, please help:
>do you have any clu, why issue 1. Code CCT is in '10_Completed' of issue
>list 1.0 and issue 2 Identifier CCT is in '10_PendingAction'?
>Does this mean, you're waiting for the feedback 'It's implemented'?
>btw the action as of todays issue list 1.0 is 'Fix in schemas.' But it has
>be to fixed in the spreadsheets and data model as well.
>
>thanks,
>Michael
>
>-----Ursprungliche Nachricht-----
>Von: Michael Dill [mailto:dill2@gefeg.com]
>Gesendet: Dienstag, 29. Juni 2004 13:27
>An: 'ubl@lists.oasis-open.org'
>Cc: David Kruppke (E-Mail)
>Betreff: two CCT issues to be added to the issue list in order to become
>CCTS compliant
>
>
>Anne,
>please add the following two issues to the famous issue list.
>There are differences between the CCT as of CCTS and the CCT as of published
>UBL, I think:
>
>1. Code CCT
>issue: different sequence of data
>as of UBL:
>Code. Content
>Code. Name. Text
>Code List. Identifier
>Code List. Agency. Identifier
>Code List. Agency Name. Text
>Code List. Name. Text
>Code List. Version. Identifier
>Code List. Uniform Resource. Identifier
>Code List Scheme. Uniform Resource. Identifier Language. Identifier
>
>as of CCTS 2.01:
>Code. Content
>Code List. Identifier
>Code List. Agency. Identifier
>Code List. Agency Name. Text
>Code List. Name. Text
>Code List. Version. Identifier
>Code. Name. Text
>Language. Identifier
>Code List. Uniform Resource. Identifier
>Code List Scheme. Uniform Resource. Identifier
>
>reason: I don't now
>proposed solution: change the sequence as of CCTS 2.01
>
>2. Identifier CCT
>issue: different sequence of data
>as of UBL:
>Identifier. Content
>Identification Scheme. Identifier
>Identification Scheme. Agency. Identifier Identification Scheme. Version.
>Identifier Identification Scheme. Uniform Resource. Identifier
>Identification Scheme. Agency Name. Text Identification Scheme. Name. Text
>Identification Scheme Data. Uniform Resource. Identifier
>
>as of CCTS 2.01:
>Identifier. Content
>Identification Scheme. Identifier
>Identification Scheme. Name. Text
>Identification Scheme. Agency. Identifier Identification Scheme. Agency
>Name. Text Identification Scheme. Version. Identifier Identification Scheme.
>Uniform Resource. Identifier Identification Scheme Data. Uniform Resource.
>Identifier
>
>reason: I don't now
>proposed solution: change the sequence as of CCTS 2.01
>
>There is no dangerous impact on schemas, because the sequence of attributes
>is not important for schemas. But it's an error and second this would cause
>problems, if somebody wants to see used versus not-used CCTypes.
>thanks,
>Michael
>
>
>
>-----Original Message-----
>From: Anne Hendry [mailto:anne.hendry@sun.com] 
>Sent: Monday, November 29, 2004 5:29 PM
>To: tmcgrath@portcomm.com.au; dill2@gefeg.com;
>stephen_green@seventhproject.co.uk; sylvia.webb
>Cc: ubl-ssc@lists.oasis-open.org
>Subject: [ubl-ssc] question on open alignment issues
>
>Hi,
>
> From original F2F report, the UBL-CoreComponentTypes Issue #2 was:
>   The order of the supplementary components for "Code. Type" and
>   "Identifier. Type" should be aligned with the one used in the CCT
>    schema and in CCTS 2.01.
>
>But I am seeing that neither schema nor ss are in CCTS order for
>BinaryObjectType.
>Should this be on the list to be fixed as well?
>
>BTW, Mark's comment on this is that there is no normative order for
>attributes.
>So, I assume we are just doing this for the sake of simplifying the tools
>work.
>Is this right, or do you see some other reason for having them in the order
>shown in CCTS?
>
>Thanks,
>Anne
>
>
>   
>
>
>  
>



Comment ID

Submitter

Submit Date

Issue

Link to Original Message

Suggested Fix

TC Discussion

Disposition

2004-08-21

Change made to spreadsheets

Schema Model BIE(s) Effected

Change to make to Schemas

1.1

cheekai@softml.net

25. May. 2004

The UBL model spreadsheet has SellerProposedSubstituteLineItem but the schema has a generated value of SellerProposedLineItem.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: Update schema to accurately reflect spreadsheet BIE name. Responses: DK/MD: Indeed! Solution porposal: We have to change the entries here!

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


OrderLineType /SellerProposedLineItem

Change 'SellerProposedLineItem' to 'SellerProposedSubstituteLineItem' and, if necessary, amend any metadata

1.2

cheekai@softml.net

25. May. 2004

The UBL model spreadsheet has BuyerProposedSubstituteLineItem but the schema has a generated value of BuyerProposedLineItem.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: Update schema to accurately reflect spreadsheet BIE name

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


OrderLineType / BuyerProposedLineItem

Change 'BuyerProposedLineItem' to 'BuyerProposedSubstituteLineItem' and, if necessary, amend any metadata

1.3

cheekai@softml.net

25. May. 2004

The UBL model spreadsheet has HandlingUnitDespatchLine but the schema has a generated value of DespatchLine.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: Update schema to accurately reflect spreadsheet BIE name

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


TransportHandlingUnit / DespatchLine (HandlingUnitDespatchLine)

Change in TransportHandlingUnit in CommonAggregates Schema 'DespatchLine' to 'HandlingUnitDespatchLine' and, if necessary, amend any metadata

1.4

cheekai@softml.net

25. May. 2004

No definition for HandlingUnitDespatchLine (because of above problem).

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: Update schema to accurately reflect spreadsheet BIE name Responses: DK/MD: yes, it's a resulting problem.

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


TransportHandlingUnit / ReceivedReceiptLine (ReceivedHandlingUnitReceiptLine)

Replace TransportHandlingUnit.ReceivedReceiptLine definition in CommonAggregates Schema with 'associates the Transport Handling Unit with one or more receipt lines on a receipt advice'

1.5

cheekai@softml.net

25. May. 2004

The UBL model spreadsheet has ReceivedHandlingUnitReceiptLine but the schema has a generated value of ReceivedReceiptLine.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: Update schema to accurately reflect spreadsheet BIE name

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


TransportHandlingUnit / ReceivedReceiptLine (ReceivedHandlingUnitReceiptLine)

Change 'ReceivedReceiptLine' to 'ReceivedHandlingUnitReceiptLine' and, if necessary, amend any metadata

1.7

cheekai@softml.net

25. May. 2004

In "ExchangeRateType", the element "OperatorCode" ought to have been defined as 'type="opr:OperatorCodeType"' because this is the specific code type to be used for this element. The release schema uses 'type="udt:CodeType"', which is a much looser type choice, and is not consistent with use of code lists within the other type definitions.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: The element "OperatorCode" ought to have been defined as 'type="opr:OperatorCodeType"' because this is the specific code type to be used for this element. Responses: DK/MD: It was changed in draft6 spreadsheets. No entry in change log.

30 Jun Atlantic: Agree. Already discussed in draft 6. 1 Jul Pacific: Agree, this was left out of change log.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


ExchangeRateType / OperatorCode

Change, for OperatorCode the type from 'udt:CodeType' to 'opr:OperatorCodeType', and, if necessary, amend any metadata

1.8

cheekai@softml.net

25. May. 2004

The above reference to "OperatorCodeType" appears to be the only place in CommonAggregateComponents that uses this type definition. Because of this switch to "udt:CodeType", the UBL 1.0 release CommonAggregateComponents schema did not find the use of the code list file "UBL-CodeList-OperatorCode-1.0.xsd" and so has not included in the <xsd:import> list. Aside: The complexType collection in CommonAggregateComponents altogether uses 12 out of 13 code lists provided in the UBL 1.0 release package. The only code list that it does not use is the AcknowledgementResponseCode defined in "UBL-CodeList-AcknowledgementResponseCode-1.0.xsd". This is used in "Order" schema. So, we should see imports of 12 code lists instead of the current 11 code list imports within CommonAggregateComponents schema.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: Fix OperatorCodeType definition in CAC. Responses: DK/MD: Thats right! Is a resulting problem from the above mentioned problem.

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


OperatorCodeType

amend namespaces and imports in accordance with 1.7 above

1.14

cheekai@softml.net

25. May. 2004

In "BinaryObjectType", the spreadsheet defines only 1 attribute named "mimeCode". The schema, however, shows a completely different attribute named "characterSetCode".

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: The schema should be corrected to reflect what is defined in the spreadsheet model, with only 1 attribute named as "mimeCode". Responses: http://lists.oasis-open.org/archives/ubl/200406/msg00035.html Tim: issue 14 impacts the issue of CCTS schemas. the data model for Binary Object is wrong in UBL, according to the original schemas from Gunther and Garrett/OAG's revised ones. in fact, the Binary Object should be all supplementary components except for MimeCode. DK/MD: It was changed in draft9 spreadsheets. No entry in change log. Tim: This was my mistake when i built the model. So before we make the schema fit the model, we should correct the model.

30 Jun Atlantic: Needs further discussion. 1 Jul Pacific: Needs further discussion. 14 July Atlantic: Appears to be another schema fix that has been decided.

Fix in 1.0 schemas. Also fix spreadsheets

Fix in 1.0 schemas and 1.0 spreadsheets.

Content, Format, Filename, EncodingCode, CharacterSetCode and URI added to BinaryObject in UDT spreadsheet and MimeCode deleted – update to schemas too

BinaryObjectType

Change the Supplementary Components in the UDT and CCT Schemas as follows: remove MimeCode from BinaryObject and add to it Content, Format, Filename, EncodingCode, CharacterSetCode and URI

1.15

cheekai@softml.net

25. May. 2004

In "CodeType", the definition text appears to have some stray wordings: <ccts:Definition> A character string (letters, figures or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an Attribute together with relevant supplementary information. Date Time. Type Identifier. Ty </ccts:Definition> The trailing " Date Time. Type Identifier. Ty" should not occur in schema.

http://lists.oasis-open.org/archives/ubl-dev/200405/msg00043.html

Chee-Kai: The trailing " Date Time. Type Identifier. Ty" should not occur in schema. Responses: DK/MD: It is wrong in our models.

30 Jun Atlantic: Agree. 1 Jul Pacific: Agree: need to change in schema (EF). 14 July Atlantic: DK/MD 'models' are assumed to be the internal EF models, so this is for EF to fix.

Fix in 1.0 schemas.

Fix in 1.0 schemas.


CodeType

Remove 'Date Time. Type Identifier. Ty' from the end of the ccts:Definition of CodeType in the UDT Schema

2.1

Jordi Bosom i Valmaña

8. Jun. 2004

InvoiceLine calculation questions - Error in Text?

http://lists.oasis-open.org/archives/ubl-dev/200406/msg00004.html


14 Jul Atlantic: This needs more input from business experts. Send to TC for possible answers from business experts.

Send to TC for additional input.

Change the description as suggested in both the spreadsheet and the schema.

For Question 1, changed definition of LineItem/LineExtensionAmount and InvoiceLine/LineExtensionAmount, changing ' (equals BasePrice multiplied by Quantity)' to ' (equals BasePrice multiplied by Quantity, plus AllowanceCharges)' This change needs to be made in the Schemas too


Change in the CommonAggregatesSchema, InvoiceLine/LineExtensionAmount and LineItem/LineExtensionAmount definitions from '...(equals BasePrice multiplied by Quantity)' to '... (equals BasePrice multiplied by Quantity, plus AllowanceCharges)'

18.2

Yukinori Saito <saito-yukinori@fujielectric.co.jp>

8. Jun. 2004

The definition of both MaximumBackOrderQuantity and MinimumBackOrderQuantity in LineItem (ABIE) says ‘customer’. This word should be changed to ‘seller party’. The word ‘customer’ is not used at any other definitions. And the word ‘customer’ is ambiguous for definition in the UBL specification.


Alter the definition of both MaximumBackOrderQuantity and MinimumBackOrderQuantity in LineItem (ABIE) as following. Alter 'customer' to 'seller party'.

TM: Customer is not a term used anywhere else in UBL. Suggested action is to chnage this term to Seller Party. 14 Jul Atlantic: Assume that the suggested fix is the best, but suspect that what is meant is 'BuyerParty', not 'SellerParty'. Raise in Pacific call. Additional input since Atlantic call: MD: See thread at http://lists.oasis open.org/archives/ubl/200407/msg00012.html items (2) and (3) for additional issues/information on this (need for controlled vocabulary and DEN consistency). AH Note: multiple issues here. 15 Jul Pacific:


TM: Customer is not a term used anywhere else in UBL. Suggested action is to chnage this term to Seller Party. 14 Jul Atlantic: Assume that the suggested fix is the best, but suspect that what is meant is 'BuyerParty', not 'SellerParty'. Raise in Pacific call. MD: See thread at http://lists.oasis open.org/archives/ubl/200407/msg00012.html items (2) and (3) for additional issues/information on this (need for controlled vocabulary and DEN consistency). AH Note: multiple issues here. 15 Jul Pacific: TM has discussed this with YS. Just change “customer” to “seller party” as suggested. 21 July Atlantic: Please confirm whether fix should be to change 'customer' to 'seller', or to change customer to 'buyer'!! Most comments say the original suggested fix by submitter was incorrect in specifying the change to be 'seller', and that this should be 'buyer', but most recent previous disposition says 'seller' (see 14 Jul and other comments above).

In the definitions of MaximumBackorderQuantity and MinimumBackorderQuantity in the reusable spreadsheet 'customer' was changed to 'seller party' (after investigations showed that it is the seller party who sets the minimum backorder quantity, etc). This same change needs to be made in the Schema


Change 'customer' to 'seller' in the definitionsof MaximumBackorderQuantity and MinimumBackorderQuantity in the LineItem in the CommonAggregatesSchema

18.6

Yukinori Saito <saito-yukinori@fujielectric.co.jp>

8. Jun. 2004

Definition of PartyName (ASBIE) in party (ABIE) is mistaken.


Mistaken: associates (optionally) the party with one or more party names. Correction: associates (optionally) the party with a party name.

14 Jul Atlantic: Raise in Pacific call.


Fix as suggested.

Changed in the PartyName ASBIE in the Party ABIE in the Reusable 'associates (optionally) the party with one or more party names.' to 'associates (optionally) the party with a party name.'


Change, in the PartyName ASBIE in the Party ABIE in the CommonAggregates Schema 'associates (optionally) the party with one or more party names.' to 'associates (optionally) the party with a party name.'

18.7

Yukinori Saito <saito-yukinori@fujielectric.co.jp>

8. Jun. 2004

Definition of Address (ASBIE) in party (ABIE) is mistaken.


Mistaken: associates (optionally) the party with one or more addresses. Correction: associates (optionally) the party with a address.

14 Jul Atlantic: Raise in Pacific call.


Fix as suggested.

Changed Address ASBIE in Party ABIE in Reusable: definition from 'associates (optionally) the party with one or more addresses.' to 'associates (optionally) the party with an address.'


Change Address ASBIE in Party ABIE in the CommonAggregates Schema: definition from 'associates (optionally) the party with one or more addresses.' to 'associates (optionally) the party with an address.'

18.8

Yukinori Saito <saito-yukinori@fujielectric.co.jp>

8. Jun. 2004

Definition of Language (ASBIE) in party (ABIE) is mistaken.


Mistaken: associates (optionally) the party with one or more languages. Correction: associates (optionally) the party with a language.

14 Jul Atlantic: Raise in Pacific call.


Fix as suggested.

Changed Language ASBIE in Party ABIE in Reusable: definition from 'associates (optionally) the party with one or more languages.' to 'associates (optionally) the party with a language.'


Change Language ASBIE in Party ABIE in the CommonAggregates Schema: definition from 'associates (optionally) the party with one or more languages.' to 'associates (optionally) the party with a language.'

18.10

Yukinori Saito <saito-yukinori@fujielectric.co.jp>

8. Jun. 2004

The definition of Extension (BBIE) in SecondaryHazard (ABIE) is inappropriate.


Correction: Additional information regarding the hazardous substance. Can be used to specify information such as the type of regulatory requirements that apply to a description.

14 Jul Atlantic: Raise in Pacific call.


Fix as suggested.

Changed, in Reusable Spreadsheet, Extension in SecondaryHazard, definition from 'identifier of additional information regarding the hazardous substance. Can be used to identify information such as the type of regulatory requirements that apply to a description.' to'additional information regarding the hazardous substance. Can be used to specify information such as the type of regulatory requirements that apply to a description'


Change in the CommonAggregatesSchema, Extension in SecondaryHazard, definition from 'identifier of additional information regarding the hazardous substance. Can be used to identify information such as the type of regulatory requirements that apply to a description.' to'additional information regarding the hazardous substance. Can be used to specify information such as the type of regulatory requirements that apply to a description'

19.5

Tim McGrath tmcgrath@portcomm.com.au

9. Jun. 2004

The definition under the BBIE, Transport Handling Unit. Received_ Handling Unit Receipt Line. states "associates the Transport Handling Unit with one or more despatch lines on a despatch advice." which is the definition of another BBIE. Suggested action is to change the definition to "associates the Transport Handling Unit with one or more receipt lines on a receipt advice."


Suggested action is to change the definition to "associates the Transport Handling Unit with one or more receipt lines on a receipt advice.

14 Jul Atlantic: Agree.

Fix for 1.0

Change the description as suggested in both the spreadsheet and the schema.

Changed in the Reusable Spreadsheet, in the definition of TransportHandlingUnit.ReceivedHandlingUnitReceiptLine from 'associates the Transport Handling Unit with one or more despatch lines on a despatch advice.' to 'associates the Transport Handling Unit with one or more receipt lines on a receipt advice.'


Change in the CommonAggregatesSchema,in the definition of TransportHandlingUnit.ReceivedHandlingUnitReceiptLine from 'associates the Transport Handling Unit with one or more despatch lines on a despatch advice.' to 'associates the Transport Handling Unit with one or more receipt lines on a receipt advice.'

20.4



Both sets of diffs picked out the error in Allowance Charge. Reason. Code This has little significant impact. I suggest amending the spreadsheet because that avoids changing the Schemas but I accept that it could be argued that the Schemas could be changed because the change is to the documentation only. The 'tag' name is unaffected. Tim: there are two things wrong with Allowance Charge. Reason. Code: firstly, the spreadsheet should have indicated this is a data type of "Allowance Charge Reason_ Code. Type" to link it to the specialized data type of the same name. So the spreadsheet does need to be changed. secondly,(and more significant) is that the DEN of this is given in the schemas as "Allowance Charge. Reason. Allowance Charge Reason_ Code" and not "Allowance Charge. Reason. Code". in fact, i think this is a mistake in all schemas where we have used a specialized code (e.g. "Exchange Rate. Source Currency. Currency_ Code" instead of "Exchange Rate. Source Currency. Code"). It seems we have been using the data type qualifer in the DEN and I thought that we had agreed these data type qualifers are only for data types and not the representation term. To quote the CCTS, it says...



14 Jul Atlantic: Check fof further in this thread for clarification (AH) and take to mail for further clarification (JB).


14 Jul Atlantic: Check further in this thread for clarification (AH) and take to mail for further clarification (JB). 15 Jul Pacific: Including the data type qualifier in the DEN is incorrect. EDIFEX is using the wrong formula. All of the codes in all of the schemas have incorrect dictionary entry names; the spreadsheets are correct (except for Allowance Charge. Reason. Code, which needs to be fixed in the spreadsheet). 21 Jul Atlantic: Agree to split 20.4 into two items (one for ss change and another for ef change) and go ahead with changes as described.

In the Reusable spreadsheet, in AllowanceCharge, changed the DatatypeQualifier of AllowanceChargeReasonCode from blank to 'Allowance Charge Reason'


In all Schemas where specialized datatypes and Schema-defined codelists occur, replace in the Dicionary Entry Names the DataTypeQualifiers with the Representation Terms such that, for example, 'Allowance Charge. Reason. Allowance Charge_ Code' becomes 'Allowance Charge. Reason. Code' and instead of "Order Change. Line_ Extension Total. UBL_ Amount" it should be "Order Change. Line_ Extension Total. Amount".

20.9



Both diffs found the Schema error Payment Means. Payment Means. Code which is incorrectly named Payment Means. Payment_ Means Type. Payment Means_ Code in the Schemas which also have an incorrect tag' name PaymentMeansTypeCode. This was changed to remove the name part 'Type' during the drafting phase of 1.0 but to change it now would produce a backwards incompatibility into 1.0. I threfore propose that the spreadsheet be changed to include the extra word 'Type'. A loose end will then be the name of the codelist. This is currently PaymentMeansCode but it cannot (as far as I can imagine) be changed so there will be a discrepancy which should probably be well documented. The documentation will need to be examined for any other mentioning of this element name to ensure it is kept consistent. (ubl-dev pointed out a discrepancy here.) Chee-Kai pointed out that the list of values included the 'Type' word but this will now have stay like that, rather than being corrected as Chee-Kai suggested. Another discrepancy is in the distribution of terms between columns which should be corrected in the Schema documentation (with no impact on instances) Tim: again, this points back to the incorrect use of qualifiers for data types in the DEN. but in this case it also appears that schemas have changed the whole structure of the name. The correct name for this BBIE is "PaymentMeansCode" not "PaymentMeansTypeCode". the schemas have not only added the word "type" to the Property Term but they have created a new qualifier! so instead of this being Property Term = "Payment Means" (as stated in the spreadsheet) we have Property Term Qualifer = "Payment" and Property Term = "Means Type" i am not sure how this happened but it reflects a real problem with the schema generation process. the only practical solution I can suggest is to modify the spreadsheets to reflect the tagname given in the schema. we can do this by changing the spreadsheet to say... Property Term Qualifier = "Payment" Property Term Possessive Noun = "Means" and Property Term Primary Noun= "Type" This creates a Property Term of "Means Type" qualified by "Payment" giving us "PaymentMeansTypeCode" as the UBL Name (and hence tag name). This also makes it consistent with other UBL BBIEs such as TransportMeansTypeCode. Of course, the schema annotations must also be changed to reflect this new naming. finally, I have no problem with the code list name being different from the BBIE - there is no fixed rule that says they should be the same. The code list name is from the qualifer of the data type.





21 Jul Atlantic: Agree with analysis, but want to make sure that we do the right thing in the fix, so take up in Pacific call to sort out possible fixes and their ramifications.



Change 'Payment Means. Payment_ Means Type. Payment Means_ Code' to 'Payment Means. Payment Means. Code' and see spreadsheet for changes needed to ccts terms

b.1

Michael Dill dill@gefeg.com

29. Jun. 2004

Differences between the CCT as of CCTS and the CCT as of published UBL, I think: 1. Code CCT issue: different sequence of data as of UBL: Code. Content Code. Name. Text Code List. Identifier Code List. Agency. Identifier Code List. Agency Name. Text Code List. Name. Text Code List. Version. Identifier Code List. Uniform Resource. Identifier Code List Scheme. Uniform Resource. Identifier Language. Identifier as of CCTS 2.01: Code. Content Code List. Identifier Code List. Agency. Identifier Code List. Agency Name. Text Code List. Name. Text Code List. Version. Identifier Code. Name. Text Language. Identifier Code List. Uniform Resource. Identifier Code List Scheme. Uniform Resource. Identifier reason: I don't now proposed solution: change the sequence as of CCTS 2.01





21 July Atlantic: Agree to suggested change in schemas, but we note that the order is non-normative in ccts. This will now be discused in ccts and the order may change in the future.



Change order of metadata as suggested

e.1

Stephen Green / Anne Hendry


How do we provide guidance on namespace construction for ubl? Do we need a rule to specify namespace urns? There is already an oasis rfc for this (rfc 3121). It appears to give some latitude to the tc to specify some components of a namespace urn, but it is currently unclear how much latitutude the tc has in providing values for this. The rfc states: “The Director of Technical Operations at OASIS assigns document types, subtypes, and all unique identifiers.” The current ndr specifies these items as well as the rest of the urn components that are clearly controlled by oasis. Does the rule (NMS [5], but also [4] and perhaps others) conflict with oasis assignment? Should it duplicate parts or all of this rfc? If we decide to have a rule for this how much should the rule cover? Right now the rule coverage is inconsistent (eg. right now we have a rule for two of the three document class identifiers specified by the rfc - 'specification' and 'tc', but not 'technical' - but on the other hand the rules cover all components of a urn specified by the rfc, rather than just the ones over which the tc may influence). See link to latest email thread and any subsequent postings, and rfc 3121 (http://www.ietf.org/rfc/rfc3121.txt). We must change all namespace urns for this last build anyway, but ased on latest discussion the current rule is not sufficient to produce these (is lacking or conflicting with rfc).

Latest link in discussion which incorporates most of recent replies: http://lists.oasis-open.org/archives/ubl/200407/msg00051.html

Get a clear understanding of rfc 3121 and oasis policy around this to know which comonents we have some control over and then based on that info decide if a rule is needed.






To be decided (Eduardo may hopefully have an answer by 28th July – see e-mails)





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