[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Re: [ubl-ssc] question on open alignment issues
Hi Anne, Michael is traveling and I do not know if he will be able to answer your questions. IMO, there are two reasons why we need schema and spreadsheets to be consistent with CCTS 2.01. They are: a) To minimize confusion for those developers and implementers who are reviewing and comparing the spreadsheets, schema, and CCTS. Consistency eliminates questions. b) To reduce the amount of development time for GEFEG. This is not a real issue but every where we can save time helps. Please remember that EF creates schema from data models not spreadsheets. We use CCTS as the basis for those models. Where schema differs from CCTS, additional programming is required. As I recall, b.1 was not done. Everyone was focused on getting 1.0 completed not aligned with CCTS or EF. Hopefully David can confirm that Michael was referring to Table 8.1 which is Approved Core Component Types. Table 8.2 is Approved Core Component Type Content and Supplementary Components. Regards, Sylvia -----Original Message----- From: Anne Hendry [mailto:anne.hendry@sun.com] Sent: Wednesday, December 01, 2004 12:52 PM To: Sylvia Webb Cc: 'David Kruppke'; ubl-ssc@lists.oasis-open.org; ubl@lists.oasis-open.org Subject: [ubl] 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 > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]