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

["Sylvia Webb" <swebb@gefeg.com>]

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