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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: RE: [regrep] Core Components and version 3


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


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


Powered by eList eXpress LLC