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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-csc message

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


Subject: Re: [ubl-csc] Re: CSC call on 26 November


Anne, the meeting to talk about this was always set for Thu 7-9,
no change there.

Anne Hendry wrote:
>> Let's continue this discussion in the call Thursday (7-9
>> a.m. California time, the usual UBL bridge, whoever gets there
>> first starts the call).
> 
> 
> Oh dear, Thursday?  What happened to Wednesday?
> There's a ttsc meeting Thursday at 8am.
> 
> (BTW, I'm beginning to really dislike 7am.   It used to be
> a fairly decent time of day: tea, muffins, and what not ...
> So please excuse any apparent grumpiness.  I (or you) will
> get used to it!)
> 
> -A
> 
> jon.bosak@sun.com wrote:
> 
>> [Anne:]
>>
>> | Speaking about the change in CSC charer, though, I'm a bit
>> | perplexed.  My original belief that the CSC was the right place
>> | for coordination and communication, not for administration, came
>> | from two inputs.
>>
>> That's right -- it's for coordination and communication, not for
>> administration.  So if we want to use it as a decision-making body
>> (i.e., one that can enforce its decisions), we will have to go
>> back to the TC for authorization to do that.  Quite rightly, too.
>>
>> [Mark:]
>>
>> | My concern is that any attempt to make CSC the coordination
>> | mechanism does not have the right people involved - at least for
>> | this particular issue.
>>
>> Hence my suggestion that we hand off specific issues to specific
>> small volunteer teams for predigestion.  But I agree that this is
>> a critical weakness of the steering committee approach.
>>
>> | It would seem to me that in reality what is needed is a) better
>> | communication from NDR, b) an agreement on what are the
>> | responsibilities of each of the subcommittees (despite the
>> | charters I believe we have allowed a certain amount of overlap to
>> | be created and this has caused the disconnects we saw in San
>> | Francisco) and c) a more effective QA effort - with active
>> | technical participation from NDR sufficiently in advance of any
>> | final review/approval cycle so that discrepancies can be
>> | identified and corrected.
>>
>> I don't think it's possible any more to say that NDRSC is strictly
>> responsible for the design rules and that LCSC is strictly
>> responsible for the content.  This was OK in the beginning,
>> because each SC knew so little about the area of responsibility of
>> the other that everyone was pretty much content to let the experts
>> in the other area make decisions in that area.  But people know
>> too much now to be happy with that; the LC people have opinions
>> about the way the design rules play out, and the NDR people have
>> opinions about the way the data is being modeled.  We've reached
>> the stage where a lot of these decisions ideally ought to be going
>> to the TC as a whole so that everyone buys into them.  (This is
>> the reality of what we've been calling "joint SC meetings.")
>>
>> | I think that technical coordination is better left to direct,
>> | pro-active efforts on the part of the technical subcommittees.
>> | Our problem in the past has been that the subcommittees have not
>> | been proactive.  I think that given the SF issues we uncovered,
>> | everyone realizes what is needed.  My proposal would be for the
>> | individual subcommittees to formally designate a technical person
>> | to act as liaison.  That person would be responsible for attending
>> | all of the other subcommittee teleconferences for the purpose of
>> | sharing decisions made in their parent subcommittee as well as
>> | identifying any issues related to decisions the liaised
>> | subcommittee is making.  I think we may also want to formalize the
>> | QA process as an entity separate from the existing subcommittees.
>> | The model for this would be the technical assessment subcommittee
>> | in X12 and EDIFACT.
>>
>> I believe that Anne's reply (which I won't quote here) nicely sums
>> up the drawbacks to this approach.  I am very well aware of the
>> essential and indeed heroic role that the ebXML QA team played in
>> seeing that project to a successful conclusion, but its efforts
>> were born of desperation and do not in my opinion represent a
>> model for how this kind of work should be conducted.  And I'm not
>> impressed by what little I've seen of the technical assessment SCs
>> in X12 and EDIFACT (though admittedly I don't have a lot of
>> experience on which to base this).
>>
>> | Ah, I see what you are talking about now.  Not a body to resolve
>> | the technical issues, rather a body to identify that the
>> | coordination of the technical issues was not being properly
>> | addressed.
>>
>> I sense that we are coming to an agreement on this as a minimum.
>>
>> | I really believe there is a need for the QA team, and agree that
>> | CSC is the proper place to discuss the relative merits of it.  I
>> | was inferring from previous posts that folks were proposing the
>> | CSC resolve differences.
>>
>> That *is* what I was proposing.  I still think that it's one of
>> the workable solutions, though it's apparent that none of us like
>> it.
>>
>> | I fully support increased coordination of schedules and the like
>> | but I would be very hesitant to give CSC the "authority to 'impose
>> | solutions'" related to technical issues. For example, in the
>> | disconnect between LC and NDR over the beta schema, that would
>> | mean that CSC would have to choose between the natural product of
>> | NDR (the design rules), or the solution implemented by LCSC (one
>> | persons preference for schema design).  Such autocracy is exactly
>> | the model that is broken in CEFACT - Autocratic decisions by the
>> | executive based on personal preferences rather than on the
>> | technical work of the subordinate groups.
>>
>> I agree that we don't want this.  The problem we've got is that
>> each *SC* sees the other SC as autocratic because the members of
>> each SC know too much not to have an opinion about the conclusions
>> of the other but don't participate enough (due to time
>> limitations) to completely understand their reasoning and buy into
>> it.  In my view, this is the core of the problem, and like most of
>> our problems, it's just another consequence of resource
>> constraints.
>>
>> [Anne, in a later reply to Mark:]
>>
>> | >But it is the technical disconnect that has caused the real issue
>> | >here.
>> | | Not sure I agree here.  If NDR and LC were one team (which is a
>> | procedural issue) I think the technical issues would have been
>> | resolved earlier.
>>
>> Exactly.
>>
>> | Even if they had begun separately bug merged
>> | part-way, I still think the same.  That's a drastic thought, but
>> | it's mainly a matter from my viewpoint of there not being enough
>> | time to have proper communication around the issues.  It could
>> | also have been resolved if enough members of each team had enough
>> | time to attend both meetings, or some other communication
>> | mechanism had been enforced.  I'm not discounting that there are
>> | tehcnical issues.  Just noting that, given we are all intelligent,
>> | capable people, I thnk they could be resolved with the application
>> | of some communication-enhancing procedures and decision
>> | guidelines.
>>
>> I think this very accurately sums up the problem, but I can't buy
>> "better communication" as the entire solution.  We do indeed have
>> "intelligent, capable people" -- the problem is that they're too
>> darned intelligent and capable (and opinionated) to be satisfied
>> with letting other people make basic decisions without them.
>>
>> [Tim:]
>>
>> | from what i am hearing on this thread i think we are near
>> | agreement along the lines of:
>> | | * CSC has the role (already) of ensuring co-ordination across SCs
>> |   - no change of charter is required
>> | * CSC does not have the right (or skills) to impose any solutions
>> |   - just to facilitate them being achieved.
>> | * We have not been doing this very well
>> | * You cannot step into the same river twice (but you can try)
>>
>> I agree with all of the above.
>>
>> | * There are some issues currently on the table that we should be
>> |   aware of and monitoring.  the ones noted in this thread so far
>> |   have been:
>> | |  - code lists
>> |  - schema generation
>> |  - publishing of NDR rules
>> |  - QA of deliverables
>>
>> To which I would add:
>>
>> - Final CCTS alignment
>>
>> - Formal contribution of our semantics to TBG17 (we're already
>>   late with this compared to some other groups)
>>
>> - Detailed consideration of RosettaNet NDR input (yes, I heard
>>   that this got some discussion today while I was out preaching
>>   UBL to Adobe, but we have a liaison issue here as well)
>>
>> - Maintenance of thoroughly detailed diffs between beta and FCS
>>   as input to the localization SCs and beta implementors (without
>>   this, the localization SCs will run completely off the rails)
>>
>> Here are my conclusions at this point in the dialogue.
>>
>> - Turning the CSC into a steering committee can probably be made
>>   to work, but we all hate the idea.
>>
>> - Better communication will certainly help, but I'm not convinced
>>   it's enough.
>>
>> - CSC issue tracking and weekly meetings should help enormously,
>>   and I'm willing to see whether this is sufficient to solve the
>>   problem if people want to give it a shot before trying
>>   alternatives.  But we will have to be really clear on who's
>>   signed up to do what.
>>
>> - If issue tracking and better communication don't solve the
>>   problem, then in my opinion the best thing to do is to combine
>>   NDR and LC for the last leg of the journey to 1.0 FCS by
>>   holding joint concalls between now and the meeting in
>>   Washington.  We've demonstrated the efficacy of this approach
>>   quite a few times now, both in person and on the phone, and it
>>   appears to me to be the simplest solution known to work.
>>
>> Let's continue this discussion in the call Thursday (7-9
>> a.m. California time, the usual UBL bridge, whoever gets there
>> first starts the call).
>>
>> Jon
>>
>>
>> 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-csc/members/leave_workgroup.php. 
>>
>>
>>  
>>
> 
> 
> 
> 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-csc/members/leave_workgroup.php. 
> 
> 

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |
W3C AC Rep / OASIS BoD



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