Re: Registry Information Model v0.41

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Hi Duanne,

Thanks for yoru detailed comments. See my responses below.

Duane Nickull wrote:

> Farrukh:
>
> I reviewedthe document you sent out.  The work is looking good.  There
> are a few comments I would like to submit for your persual.
>
>  RIM v 0.41
>
> Line 328-331:  remove java classes.  ebXML must remain technology (ie:
> programing language) independant.

The following excerpt from the lines you quoted are repeated below for
references. Note that the point being made is that process can be described in
any form (registry is neutral to teh representation). java classes are used as
an example of technology neutrality and not technology specificity.

9.1.2 Process 327
These are objects that represent a business process. These could include a 328
process description in an XML form such as XMI or could be actual software 329
components (e.g. Java Classes) that could represent an implementation of a 330
business process 331

>
>
> Line 342:  reads URI to object in "Registry" - change to Repository.
> Items do not actually reside in the Registry.

A decision was made at Tokyo to not use the term repository anywhere in our
documents. The repository is a hidden implementation detail. From the external
perspective all there is is the registry and objects that reside in the
registry.

>
>
> Line 243:  I beleive the Oasis element is "commonElementName" - I may be
> wrong.

I used a specific version of the OASIS specs. Len has this changed?

>
>
> Line 347:  We should use the xml:lang attribute to xpose descriptions in
> various languages

This table is not modeling an XML DTD or schema.

>
>
> Line 360:  Who defines the "roleName"?

There is no mention of roleName in the entire document. Are you referring to
fromRole and toRole? If so they are defined by the same person/organization that
defines the association.

>
>
> Line 365:  Is the Contains::Aggregation/composition referring to an
> Object comprised of several smaller objects?  If it is,  is this not
> what the "package" object can appropriately define?

No. Package is meant to be a very loose form of logical grouping of content. A
Package may have nothing to do with Contains::Aggregation/composition. I suppose
a registry implementation is free to use Associations as a way to implement
Package support (but that is an implementation detail)

>
>
> Line 365:  Uses/Used by may get a bit large in implementation.
> Recommend it be depracated except for referring to its' use within ebXML
> defined processes/aggragates.

There is no requirement that every content used by another content use such an
association. So it will be as large as it needs to be.

>
>
> Line 367: Section 11 -> recommend you read the thread on XML taxonomies
> started by Karl Best.  IN particular the response I sent describing
> multiple classficiation schemes may be of use.

I have been reading it. AFAIK ebXML already support multiple classifications on
the same content. Such classifications can also be context sensitive. Did you
read chapter 11 on classifications. I would be interested in what you think is
missing in support for multiple classifications.

>
>
> Line 429:  This is an ugly place.  The expression of contextually
> sensetive classifications is very obfuscated.

This is a complicated topic. I did the best I could to express a very
complicated topic by slowly building up the level of complexity and using simple
examples that anyone can relate to expressed concisley as pictures. I would
appreciate any suggestions on better expression.

>
>
> I personally beleive that the logic for accomplishing this is best left
> to ebXML applications, not as an expression of information in a
> Registry/Repository.

I humbly disagree. Context sensitive classifications are a powerful asset to
discovery. It gives the precise controls to discard content that is classified
by some ClassificationNode but using a context that is not relevant to the
query. For example if I only care about PartyProfiles that "shipTo" Japan then I
should not see PartyProfiles that are "locatedIn" Japan. It provides the ability
to express more meaning and intent in the query.

>
>
> Line 488:  Must be a contextual query.  You must be able to find
> "foo:111" inside the element "specificElement".  Otehrwise the system
> will not work in an automated environment.  This is tracable back to the
> TA document.  A plain text search is not acceptable via the Registry
> service interface.

I will study this further. Note that the solution has to work for XML and
non-XML content.

>
>
> Line 491:  Good Thinking!!!
>
> Finally,  I would like to be named as a contributor to the document if
> you decide to use any of the comments herein.

I would be glad to include you on the next rev. Thanks for your participation
and contribution.

>
>
> Excellent work.
>
> Duane Nickull
>
> Farrukh Najmi wrote:
> >
> > Attached is the latest Information Model Spec for your review. This is
> > essentially the same content that was reviewed at Tokyo f2f.
> >
> > Changes are as follows:
> >
> > -Changes based on Tokyo face-to-face meeting.
> > -Context sensitive classifications
> > -Reformatted to conform to ebXML document standard.
> >
> > It is proposed that this version be submitted to Quality Review modulo
> > changes based on feedback.
> >
> > I look forward to your comments and suggestions.
> >
> > --
> > Regards,
> > Farrukh
> >
> >   ------------------------------------------------------------------------
> >                                  Name: RegistryInfoModelv0-41.pdf
> >    RegistryInfoModelv0-41.pdf    Type: Acrobat (application/pdf)
> >                              Encoding: BASE64

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard