ebxml-regrep message

[Date Prev] [Thread Prev] [Thread Next] [Date Next] -- [Date Index] [Thread Index]

Subject: RE: Thoughts on Classification support in RS


I've made notes below, and as you say - discussion on 
conference call today!

Thanks, DW.

Message text written by Farrukh Najmi

General Requirements
o Need tight alignment with BP, CC, TP meta-model work

o Need all access to objects and to RS to be over ebXML TRP
>>>>>>> NO, NO!!!  This has been postulated before, then 
                 dropped by TRP itself, and removed from the TA,
                 and Requirements states separate access.
                 Clearly, while we want to support the TRP security 
                 model, the mechanisms here are VERY different.    

Object MetaData Requirements
o Need to associate meta-data attributes with objects. Such attributes
may be specialized based on the type of object

Classification Requirements
o Need to classify objects on multiple dimensions
o Need to allow an extensible user defined classifications on an Object
o Need to define any number of associations between objects
o Classification scheme mechanism should be general enough that
classification can be provided by project team in the same manner as
user defined (or industry defined) classification schemes.
o Need to support standard coded schemes
>>>>>>>>> These are primarily OASIS Registry functions.  Our need is
                       to provide industry and coded table support
directly, else
                       there is no ebXML standard!!!  We would be back to 
                       everyone doing there own thing and we've achieved
                       nothing!!!   Summary OASIS - General; ebXML -
                       directed specifications.

Query Requirements
o Need to support conjugation (AND, OR, NOT) of simple predicates into
complex predicates. E.g. Find all Parties that sell computers AND are
located in the Boston area
o Need to support inheritance in classification schemes. E.g. Find all
parties that sell automobiles should find all parties that sell cars or
trucks if there is an inheritance relatioship between automobile, car
and truck
>>>>>>>>>> Wooahhh!  This is a funcition of the IMPLEMENTATION
                         behaviour.  We can say this is a nice to have, but
                         require it. You want this to be multilingual as
                         Think simple.

o Need to support range of values in a concept. E.g. Response time is
BETWEEN 0 AND 6 hours
>>>>>>>>>> The DASL approach to QoS works here.

o Need to support membership in a set. E.g. Find all parties that sell
o Need to support sorting. E.g. Find all parties that sell Digital
Cameras and list them sorted by their customer satisfaction rating
o Need to support comparison operators. E.g. Find all suppliers of
CoolPix990 where the price is < 830.
>>>>>>>>>>> This is same as AND, OR, NOT.  Sorting can be a 
                            backend function.  IMPORTANT POINT - hey, 
                           RegRep is not and application!!!  You seem to be

                           making it into one.

o Need to support aggregate expersion (MIN, MAX, Average, SUM) etc. for
cheapest price, longest warranty etc., better than average performance
>>>>>>>>>>> No. No. No - this is not an application we are building!!!
                           Other people can figure this crap out, once they
have the raw

Issues With Current Proposal

I first started listing which requirements where *not* being met by CP.
When it seemed like they were unfortunately a large
list I decide to invert things and list which requirements from above
*ARE* being met:

The following requirements do seem to be met in CP.

-Need to associate meta-data attributes with objects.
>>>>>>>>>>> I think we can wait on this till UML/MOF is real in this
                           area.  We cannot solve everyones problems.  We 
                           provide a service - its up to these other people
                           figure out how to use it to do this stuff, not

-Need to support standard coded schemes
>>>>>>>>>>>> Sure - I do NOT see an issue here, we do this 

The following general issues were observed:

-Specific technology is being recommended (e.g. WebDav/DASL). This is
not consistent with ebXML vision and purpose
>>>>>>>>>>> What?  TRP recommend http/MIME - so we are not allowed 
                           to pick an existing standard??!

Please forgive me if I have misinterpretted anything or missed any other
requirement that is being met. Reading through
a 26 page document can have its limitations. All in all I feel that this
proposal is too far off the mark. Please understand that I have been
very objective and fair. I do not just want to find nits in hard work
put in by my esteemed team-mates. I would like to humbly recommend some
alternatives we should consider that will make us meet the requirements.

Recommended Approach

Registry Information Model

The registry information model defines:

o How managed objects are organized in the Registry
o Is based on ebXML meta-models from various working groups
>>>>>>>>>> Agreed - but those groups are woefully behind on 
                        getting these to us.

o Provides a basis for relational or object schemas for an RS
>>>>>>>>>>> Yes, but lets pick which one we do first.

Managed Objects
o Define some built-in types of ManagedObjects based on WG meta-models
(e.g. TPA, TPAElement, Schema, SchemaElement, BusinessProcess  etc.)
>>>>>>>>>>>> Great, and GUIDE gives a jump start here.

o It should be possible to have any number user defined managed objects
that are of the generic ManagedObject type.
>>>>>>>>>>>> Careful here - this is the OASIS approach - for ebXML 
                             we want a specific initial list for V1.0 -
then once people 
                             are using those they can extend and enhance.

o A built-in object type may provide methods for supported associations
(e.g. A TPA may provide a method to get its Parties), that can be used
in queries.
>>>>>>>>>>>>>> Once again GUIDE is strong in this area.

o Each identified managed object typedefines its own unique meta-dat
attributes as well inherits such attributes from its super class in the
>>>>>>>>>>>>>> GUIDE element layer does this.

o RS supports queries on these attributes defined for managed objects.
>>>>>>>>>>>>> YES!  That's the approach I'd taken with the DASL 

Associations  Between Managed Object
A managed object may be associated with 0 or more managed objects.
>>>>>>>>>>>> Sure, both OASIS and the GUIDE approach support this.

An association has the following attributes:
o An association has name
o An association has a type
o An association may be directed or may be bi-directional.
>>>>>>>>>>>> Bi-directional is difficult to manage - suggest we do via
                             index of links and let users manage these, not
the engine.
                             Remember we want to make RegRep simple to do
                             COTS tools to get implementations out there

Classification By Concepts
A concept is the basis for a classification scheme:

A Concept is:
o Are ManagedObjects
o Have an id (code)
o Have a name
o Support inheritance
o Support containment
o Support associations
o Support collections
>>>>>>>>>>>>> GUIDE approach can do all of above.

Classification Scheme Support
o Objects are classified by their having an Association with a Concept
o An Object can be classified in multiple dimensions by having multiple
associations with multiple concepts
>>>>>>>>>>> We've yet to see how BP/CC actually propose to make
                           this happen in reality via XML.  This looks
                           like a V2.0 feature set.

Query Support

Much more on this later. Running out of time but suffice to say it will
address all the query requirements.
Forgive the typing errors. My final recommendation is that I put the
above ideas down in more detail and clarity
for your review by next week.


Farrukh - I think you are putting the bar WAY to high here.  Let's 
go for a MUCH simpler model that we can get done by 21st - and 
for the other stuff - lets have a 'to be done' section and drive on.


[Date Prev] [Thread Prev] [Thread Next] [Date Next] -- [Date Index] [Thread Index]

Powered by eList eXpress LLC