Re: Registry Information Model v0.41

[Duane Nickull <duane@xmlglobal.com>]

Farrukh:

Some inline comments:

Farrukh Najmi wrote:
> 

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

Okay, I comprehend now.  Maybe a sentence to clarify this may be a good
idea for the spec.

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

Awesome!  I have been advocating this since day one.  This opens the
door for decentralized repository deployment models (Webdav).

Still,  it is probablly imperative from a technical perspective that we
do not say the objects reside in the Registry.  A better wording may be
something like " the objects are referencable in a registry".  These
items may reside on a person's web server but be indexed in the
registry.

Also - not my own POV but some in ebXML have an issue with the use of
the word "object". I am sure others will bring this up.


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

But it is still a good idea.  The ebXML vision is a "global"
marketplace.  This is in the Requirements document.  I would highly
recommend that Reg/rep consider adding this for certain elements at
deployment time such as "description".  This will be loved by non
english speaking users.

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

My bad.  I neglected to leave a space in between role and Name.  Yes - I
read this.  I will paraphrase my question.  How do you ensure that the
"roles" in fromRole and toRole are consistantly defined in a way that
will enable automated discovery during the Discovery Phase?  


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

Yes - but the mechanism is there and if it gets too big,  performance
may grind to a halt.  Those of us who work with contextual searching
know the overhead involved and it doesn't always scale well.  I guess
the only way to find out is watch the first deployments and see how
often this gets used.


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

No - I agree with you.  It is very complicated and your approach to
start slow is good.

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

Yes it does allow you to provide  more meaning and intent in the query. 
But when you do that, the extra meanign and intent turns into processor
overhead on the registry server.  This will not yeild a scalable
implementation model.  Keep the overhead decentralized.  The query
should return the entire document thenthe processing to perform context
sensetive classification should take place on an ebXML application.  The
functionality is exactly the same.  The difference is that the proposed
model will not yeild an efficient deployment (performance). 

This work is looking good!  

Thanks for replying so soon.

Duane Nickull