Re: [ubl-csc] Revised outcomes of coordination call 12 December 2003

[Anne Hendry <anne.hendry@sun.com>]

Hi Jon,

Regarding CCTS alignment I have a clarification and questions as well.


jon.bosak@sun.com wrote:

>2003-1212-05 Achieving final CCTS alignment
>
>    - TTSC had some concerns that CCTS was a moving target.  It
>      seems that this is not true; CCTS 2.01 appears to be quite
>      stable.
>
>    - TTSC also has some concerns about possible ambiguities and
>      areas of the CCTS that may need interpretation.  We
>      identified Sue Probert as our liaison in these cases.
>
My understanding is that this is not a TTSC-only concern.  This was
first raised in LCSC.  Your first bullet here, though, exemplifies
the issue I was trying to raise (both as an LCSC member and TTSC Co-Chair)
which includes, at minum, these questions:

    - who owns deciding what version of ccts is supported by which 
version of ubl
    - how does that information get communicated to the scs that are 
impacted by the decision
    - how do we minimize the risk of adopting new ccts versions

Currently, AFAIK, UBl 1.0 Beta supports CCTS 2.0.  But you note above
that ccts 2.01 is quite stable.  So this already raises questions:
When did it become stable?  Are we expected to move to 2.01?  Or
have we already moved to 2.01?  If not, will we move to 2.01 for the
final UBL release?  Is 2.01 available to the public now?  If so, where?
What were the changes?  What do we do if CCTS 2.02 comes along in the
meantime, or there is 'one more small change' to CCTS 2.01 - what is
the cutoff date for CCTS changes?

The fact that there is a 2.01 seems to me to support the statement
that ccts is a moving target.  But that's not really the point,
since everything is a moving target.  The bigger item to decide
is captured in the questions above.  Since CCTS will change over
time - as does everything - what is our process for aligning with
and minimizing the risk of adopting, changes to ccts?  A risk,
for instance, of backward incompatibility, which is a user concern.
Quality of implementation is another concern.  Who does this type of
evaluation?  Since tools are beginning to be developed, this latter
question is more of the ISC/TTSC teams, but only because these teams
are a bit more outward-facing.  Overall this is an issue for all of UBL.
Each change will have a much larger ramification than it does now.
UBL will be seen as responsible for user ramifications, whether
the changes stem from UBL proper, or from CCTS changes (or from TBG17
alignment).

So, evolving this discussion, I think we need a more concrete process
for handling our dependency on CCTS and communicating our requirements
back to them.  There was some discussion of CCTS work moving to TBG17,
becoming more of an alignment question than a ccts core quetion.
It was unclear if this is something that will produce more changes
we will be expected to respond to for UBL 1.0, and how we may fit that
into the less than 2 monhts we have to finish UBL 1.0.  The timeframe
for submission to TBG 17 (Feb 2) leaves absolutely no time at all for
a response from TBG 17 that might require tweaks to UBL.

The answers to these questions also should be incorporated into the
discussion of what it means to be "UBL compliant", since there may
need to be different answers to that question for different versions
of UBL and various states of CCTS and TBG17 alignment.

-A