Re: [regrep] Core Components and version 3

[Chiusano Joseph <chiusano_joseph@bah.com>]

<Snip>
In other words, the opportunity for us to change the current CCTS
before it becomes official may have past last December.
</Snip>

Yes, and that is exactly my concern - there is definitely a hole in the
process somewhere.

<Snip>
So, I'd see the scenarios this way:
</Snip>

This is all good, but the bottom line still remains - that there is a
specification "out there" that conveys ebXML Registry functionality in a
normative way that does not yet exist.  There has been inadequate effort
on the part of that group to ensure that the functionality is feasible,
acceptable by us, and able to be incorporated into our specs.  This is
the burning issue, the timing is secondary.  I strongly recommend that
we determine the functionality in the CC spec that we cannot/should not
incorporate into our specs, and let the CCTS Team know that officially. 
That is why I am suggesting that Kathyrn take this up with higher
powers, as it is a key inter-consortium issue.

- Joe

"MACIAS, Paul" wrote:
> 
> Joe,
> 
> As I understand it CCTS is done with public reviews for edits.  That step was completed late last year.  I believe the March 10th date is the date CCTS expects their standard to be ratified by the CEFACT TMG Plenary as having completed the process and made an official CEFACT Technical Specification. I don't have access to Mark to confirm this, so this is my understanding from other sources.
> 
> The CCTS 1.9 release statement in December, and that in Section one of the specification, indicate that CCTS 1.9 is entering phase 6 of the TMG's Open Development Process.  An explanation of their process is at:
> http://webster.disa.org/cefact-groups/tmg/developmntprocess.html
> 
> As >>I<< interpret the TMG's ODP I believe CCTS is looking to provide proof of external validation (ODP, step 7) during the March meeting so that the TMG Plenary will accept CCTS as an official CEFACT Technical Specification. Whether CCTS has their ducks in a row to get TMG signoff that they've completed step 6, I'm not certain.  But, unless it fails the external validation there is not another editing round for the specification under ODP. (Again, as I interpret their ODP.)
> 
> There would still be a need for us to analyze 1.9, but if I have the above correct it would be against 1.9 as currently written.  Any changes we'd recommend to CCTS would be their next specification development cycle (like us having released V3 for external validation under the OASIS cycle).  In other words, the opportunity for us to change the current CCTS before it becomes official may have past last December.
> 
> So, I'd see the scenarios this way:
>   1)Put V3 out for public comment w/o CCTS analysis and address any CCTS incorporation comments as having been considered  but timing of CCTS release along with other priorities lead the group to determine that the analysis of incorporating CCTS and expected impact to make possible modifications would delay V3 too long.
>   2)We spend the time to analyze the potential impacts and make the call as to whether delay V3 is acceptable.  (I understand that you've provided a sampling of the comparison analysis in a earlier email and probably have more running around in your head that lead you to estimate about a month. If I'm interpreting the April to May activity below properly.)
>   3)We jump right in to make the analysis and plug away at incorporating modifications we agree are appropriate.
> 
> I don't think #3 is desirable by the group given how close V3 is for public review and the uncertainty of just how long a delay would be needed until the analysis is completed.  Option #2 would lend more specifics as to why CCTS may not be doable in V3, but it would mean taking the time to do the comparative analysis and that may be too long for some of us.
> 
> Regards,
> 
> Paul
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Thursday, February 13, 2003 10:10 AM
> To: MACIAS, Paul
> Cc: Farrukh Najmi; OASIS_RegRep (E-mail)
> Subject: Re: [regrep] Core Components and version 3
> 
> Absolutely Paul.  I fully agree that we should *consider* the
> possibility of delaying V3 in order to incorporate Core Components in an
> explicit manner.
> 
> Regarding timeframes - if the CC spec is in review March 10, we're
> talking roughly beginning of April for end of comment period.  Ideally
> there should be a period after that in which we analyze the CC spec and
> determine what requirements we cannot/do not want to meet - and convey
> this to the CCTS folks.  That will probably bring us to beginning of
> May.  Then, 3 months *minimum* to enhance the V3 specs for Core
> Components - this includes the TC voting, etc.
> 
> Bottom line - it will bring us to August 1st at the earliest; a 5 1/2
> month delay of the V3 spec.
> 
> Comments?
> 
> "MACIAS, Paul" wrote:
> >
> > Farrukh and Joe,
> >
> > Having started my ebusiness life in the arena of EDI where specific business requirements battled with development of generic specifications, I definitely appreciate the balance between making a specification too narrow vs. too ambiguous. My impression is that ebXML has been very well constructed in striking such a balance.  As Joe has expressed in a recent email, I too would not be comfortable in opening up specifications for dumping in every concept that another group desires be included.  But I do believe there are points of CC that have merit for consideration in RegRep that Joe's experience with CC is much better at articulating than I.
> >
> > I do disagree with what I interpret from various comments that its too late to discuss CCs at this time. It is completely fair us as the ebXML RegRep members to decide that V3 should not wait for CC.  That is a committee's prerogative.  However, IMHO I do not think prior to publication that it is ever too late for a standard to consider and discuss possible modifications, no matter how significant, in order to make the standard better.  We just saw this with the group's agreement to delay ebXML for the benefit of a modest effort to include XACML.  I like the principle of liasoning with other specifications as a way of heading off eleventh hour input, but I do not think lack thereof negates late consideration.  Let's remember that V3 is going to go out for public comment.  CCTS did not initiate this discussion, I did.  And I did so based on recent experiences in the Fed CIO Council world and what I heard from a CCTS member.  Regardless of the outcome, I feel having this d!
is!
> cussion
> > now has provided us the basis for responding to a likely comment.  And as a relative new comer to ebXML, I personally have appreciated all the valuable history and technical perspectives you two and others have provided.
> >
> > Thanks,
> >
> > Paul
> >
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Thursday, February 13, 2003 8:44 AM
> > To: Farrukh Najmi
> > Cc: MACIAS, Paul; OASIS_RegRep (E-mail)
> > Subject: Re: [regrep] Core Components and version 3
> >
> > I think there is a bigger issue here than timing (please read on).
> >
> > First, I would like to convey the discussions and decisions that have
> > been made to date between our TC and the CCTS Team regarding the
> > representation of Core Components in the registry architecture.  What
> > the CCTS team is looking for (and what we had been pursuing in the CC
> > Review work last year) is an explicit representation of Core Components
> > and their associated entities in our registry architecture.  This would
> > mean that a Core Component would be a new Registry Entry class in the
> > ebRIM (as is Service, for example), and its associated entities would be
> > explicitly defined Registry Objects.  This would mean that ebRIM Figure
> > 1 (p.11 of the v2.1 spec, for example) would change dramatically to
> > include Core Components and their associated entities.
> >
> > Here's why we came to this decision (please note that we are thinking
> > very much in terms of inter-registry coopreration here) - we felt there
> > were 3 (possibly more) ways in which implementors could "core
> > component-enable" their registry products:
> >
> > (1) Take our V3 specs and the CC spec, and implement the CC requirements
> > however they would like
> >         - Obvious disadvantages: Difficult to implement, prone to error,        low
> > level of interoperability (each implementor "does it their own way")
> >
> > (2) Take our V3 specs and a "core component-enabler" toolkit, and apply
> > the toolkit to their implementation once the V3 requirements are met
> >         - This implies no change to the V3 architecture, but the creation of a
> > "core component-enabler" specification extension that helps implementors
> > meet the Core Components requirements
> >         - An example would be specifying that a Core Component Registry Object
> > (if it were represented as such) would have a Slot with name "Core
> > Component Type" and possible values of "Basic" or "Aggregate" (not "B"
> > or "A")
> >         - A "toolkit" could be built by an implementor from the "core
> > component-enabler" specification extension, that specifies how to use
> > slots to accomodate the attributes for Core Components and their
> > associated entities, the various names/descriptions that should be
> > assigned to registered objects to meet the Core Components requirements
> > etc. - presumably an installer of the product would run such a tool
> > after initial installation to "core component-enable" their registry
> > installation
> >         - I contend that it would be just as much work (if not more) to create
> > such a specification extension, and therefore it would be best to
> > specify the Core Component requirements in our existing specifications
> > (hopfully v4)
> >
> > (3) Utilize our "core component-enabled" specs, in which Core Components
> > and their associated entities are part of the information model
> >         - Highest chance for interoperability - i.e. when one registry asks
> > another registry "give me all Basic Core Components whose Core Component
> > Type is Amount.Type", there is no ambiguity as to what is being asked
> > and what is being retrieved and passed on.
> >
> > Secondly, I would like to emphasize that the CC Spec contains some
> > assumptions regarding our registry functionality that we may not want
> > to/be able to incorporate into our specs.  I would encourage each of us
> > to look at p.88 in the v9 CC Spec (attached), Section 7.5 "Core
> > Components Storage Metadata".  On p.89 in particular (figure 7-4), you
> > will see depicted "Registry Metadata", much of which is not currently
> > part of our information model.  Updating the RIM (which I believe is the
> > best approach) to accomodate this is not a small task.
> >
> > *Additionally*, you will see existing registry classes such as
> > Association, with attributes that do not currently exist in our
> > architecture - for example, a "StartDate" and "EndDate".  We voiced our
> > concern to the CCTS Team (in our review comments) that the CC spec did
> > not demonstrate a sufficient reason to add these attributes to our
> > associations, and that there could be negative ramifications in the
> > registry functionality (for example, what happens when an association
> > expires?  Should expiration be "blockable"?, etc.).  Association is just
> > one example.
> >
> > Thirdly, I am concerned about the lack of interaction between our TC and
> > the CCTS Team, and where this may lead.  As I mentioned in an earlier
> > e-mail, I don't think it is wise for us to "allow" (using term loosely)
> > any other group to expand our architecture and pass a spec through an
> > approval process without our input and (hopefully) concurrence.  We did
> > express some concerns during the last comment period, and I am not sure
> > that the results reflect what we would have hoped.  I am very concerned
> > that this specification is proceeding through an approval process, and,
> > if approved, we are being looked upon to meet each and every requirement
> > within it.  As you have already seen, "promises" have been mentioned
> > that were never made - I don't want a situation in which we are told
> > that we promised to meet every requirement in this specification (when
> > we did not), and tensions result.
> >
> > Kathryn, I would like to propose that you consider taking this issue up
> > with the UN/CEFACT side, making it clear that we are under no obligation
> > to honor all of the requirements expressed in this spec.  I recommend
> > that we make it clear that we will use our judgment and honor each and
> > every one that we feel we are capabable of honoring, and for those that
> > we believe are defined ambiguosly, incompletely, or simply will not add
> > any value to the registry architecture, we reserve the right to not
> > incorporate them in our architecture.  Another approach is to allow us
> > to reply to the CCTS Team during the comment period, clearly stating
> > those aspects that we cannot honor so that there is no misunderstanding
> > in the future.  Then when we incorporate the CC spec into our
> > architecture, we can include a list in our specs of those CC spec
> > requirements that were not incorporated.
> >
> > Thanks for reading this very long e-mail.
> >
> > - Joe
> > Farrukh Najmi wrote:
> > >
> > > Hi Paul,
> > >
> > > First let me declare that I am very supportive of the CCTS work and very
> > > much want ebXML Registry to bend over backwards to meet all requirements
> > > for a CC Registry. CC registration and discovery was one of the main use
> > > cases for ebXMl Registry since its origins and continue to be a dominant
> > > use case.
> > >
> > > That said, I agree with those that suggest we should not have a direct
> > > binding to CCTS in ebXMl Registry V3.
> > >
> > > My  reasons  are very simply that:
> > >
> > > -I do not believe it is necessary to have a hard binding to CCTS in
> > > order to meet their requirements. If there are requirements we are not
> > > meeting then those requirements should be identified for being addressed
> > > generically in V4 as a high priority. Today I believe ebXML Registry is
> > > a generic registry and should not have special case handling for
> > > specific types of content. If there is a good case for special handling
> > > of CC then we can do this with careful consideration in V4.
> > >
> > > -V3 is pretty much done at this point as far as scope is concerned. We
> > > are now shooting for final iterations to get to a version that can be
> > > put to TC vote for TC approval and later for OASIS standardization.
> > >
> > > -CCTS is not an approved specification (someone made this point already)
> > > and is therefor a moving target.
> > >
> > > I believe we should work closely with the CCTS team to ensure that all
> > > the CCTS requirements are met in V4. I believe that we meet most CCTS
> > > requirements in V3 already. As a starting point I would like to propose
> > > that:
> > >
> > > -The CCTS team provide a document to our TC that identifies those
> > > requirements of CC Registry that are not yet met by ebXML Registry V3.
> > >
> > > -The CCTS team provide a liaison to ebXMl Registry TC to complement
> > > Joe's role as ebXML Registry liaison to CCTS.
> > >
> > > Please consider this opinion as constructive feedback to your suggestion
> > > and not in any way a disagreement with the goals behind your suggestion.
> > >
> > > --
> > > Regards,
> > > Farrukh
> > >
> > > MACIAS, Paul wrote:
> > >
> > > > Hey gang,
> > > >
> > > > Following on the discussion of the last ebXML Reg/Rep telecon I
> > > > thought more about the discussion that took place with regard to
> > > > incorporating ebXML Core Components into the specs.  If you
> > > > remember, Joe and I expressed our feelings that Core Components were
> > > > an important part of government implementations of an XML
> > > > registry. Farrukh also expressed that the specification is currently
> > > > flexible enough to accommodate registering almost any object, even if
> > > > the specifications do not directly call out how Core Components would
> > > > be rolled into an ebXML registry.
> > > >
> > > > I'd like to recommend that the ebXML Reg/Rep team seriously consider
> > > > explicitly calling out Core Component support in version 3 of the
> > > > specs.  My reasoning is two fold:
> > > >
> > > > 1) As previously noted, the need to register components among the
> > > > government users I'm familiar with is a key part of their XML
> > > > strategy.  Registering the components and their aggregates is seen as
> > > > a tool for heading off incompatible constructs by developers.
> > > > Harmonizing XML practices down to the element level are very important
> > > > to EPA and the Navy who are blazing an XML trail for the Federal
> > > > government.  Both these groups are ready now for a registry solution
> > > > that can meet this need, and I do not think they will be
> > > > comfortable unless Core Components support is normalized within the spec.
> > > >
> > > > 2) I have discussed this Mark Crawford of the Core Components
> > > > Technical Specification (CCTS). He relayed strong concerns that the
> > > > CCTS members had some time ago been promised that the ebXML Registry
> > > > specification would include Core Components in version 3 and that the
> > > > participants of CCTS would likely look disfavorably on version 3
> > > > otherwise.
> > > >
> > > > Considering that there is a user need looking for this functionality
> > > > and since CCTS is a sister specification under ebXML, can we
> > > > incorporate Core Components?  Specifically, I'd suggest that the
> > > > registry specs look at explaining how it supports section 5 and 7 of
> > > > the ebXML Core Components TS, version 1.9 (11 December
> > > > 2002).  http://xml.coverpages.org/CCTSv190-2002.pdf
> > > >
> > > > A cursory look indicates that there would be a couple of ways to
> > > > approach incorporating Core Components.
> > > >     a) Insert Core Component explanations at the points they are relevant
> > > >     b) Create a Core Components chapter that provides specific
> > > > information with links to the related points in the other sections.
> > > > My gut reaction would be option 2 as being cleaner to write and read.
> > > >
> > > > I'd appreciate your thoughts on the matter.
> > > >
> > > > Regards,
> > > >
> > > > Paul A. Macias
> > > > LMI
> > > > Research Fellow
> > > > 2000 Corporate Ridge
> > > > McLean, VA 22102
> > > > (703) 917 - 7101
> > > >
> > > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano