Re: [regrep] V3 Proposal: Namespace Manager Function

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

David,

I am a big fan of Lego.

I believe that the content-based-query feature is the ultimate Lego example.

-A ContentIndexer is a web service that conforms to an interface defined by a
normative WSDL in a future spec.

-Custom ContentIndexers can be written that conform to that future spec

-A ContentIndexer is registered for each type of content by a submitter

-Whenever the registry receives content it checks to see if there is a
ContentIndexer registered for that type of content. If
so it invokes it.

-The ContentIndexer renders relevant (as decide by the indexer) information
from content
into classification data based on *existing RIM 2.0*

-Users can now perform *existing SQL and Filter queries* to discover content
based on the auto-idnexed metadata

-Joe's namespace problem is addressed by defining a required ContentIndexer for
indexing XML Schema and
instance documents using the (soon to be) *existing* content-based-queries.

I'd say that is playing pretty good Lego where content-based-queries build on
and generate *existing* Classifications and
Namespace Indexer builds on the (soon to be) *existing* content-based-queries.

If we dont use content-based-queries then *WHO* does the creation of the
classification and other metadata? Cant rely
on us humans to do this sort of thing, can we?

(BTW, Thanks for helping the CC folks understand how to leverage our existing
capabilities better. It is a worthy cause.)

--
Regards,
Farrukh


David RR Webber - XMLGlobal wrote:

> Message text written by "CHIUSANO, Joseph"
> >The Namespace Manager proposal calls for the first 2 elements above to be
> associated within the registry with the http://www.acme.org/invoices
> namespacem and the 3rd element above to be associated with the
> http://www.acme.org/temp namespace.  This would allow Acme to (for
> instance)
> determine at a review time all of the constructs associated with the
> http://www.acme.org/temp namespace (i.e. all constructs that should be
> reviewed).
>
> This is just one simple case where I believe this functionality could be
> useful.  I am hearing clients express a need for this type of functionality
> more often every day.
> <<<<<<<<<<<
>
> Joe,
>
> The more I think about this - the more I think this is the tail wagging the
> dog.
>
> In the eBTWG work on core components I'm being gently admonished for not
> being the UML zealot and using the modelling tool to drive down into
> the content generation [ well that's what some people think anyway ; -) ].
>
> Now I'm seeing here we're looking at a situation where the
> information "model" is hidden in these namespace linkages in the
> schemas, and not even the programmers can "see" the wood for the trees.
>
> This was the classic problem with XSD the way Microsoft allowed - as
> a proprietary extension - inline declarations of namespaces within
> the XML content and then using them like includes.
>
> Result = you can look at the XSD all you like - but you have no way
> of knowing what the actual content is allowed until someone sends
> you a sample message.   DTD's may be dumb - but at least there
> are no hidden surprises - looking at the DTD allows you to exactly
> know the content model.
>
> Now - it seems to me that building around the Classification system
> in the Registry is the proper way to go here.   It avoids hard wiring
> this to any one particular schema flavour de jour - and provides a very
> nice potential tie in to the UML and CCR/ CRI along the way.
>
> Notice - if someone wants to write a Perl or Python script to
> run thru Schema, or RELAX or DTD's or EDI messages, and
> trawl out the heirarchy and generate nice Classification tree
> constructs from that - that's a cool tool.   But we should not
> have to specify all that in our spec's.   We simply allow for
> a link between the logical classification node and the
> physical content path.  I believe we have that already!
>
> And then the "Search on Path content" filtered query can also be easily
> vendor implemented using the underpinning - as a menu option.
>
> We should resist the urge to spawn another flavour of Lego brick
> everytime someone has a use case we've not encountered
> before.  Making people exploit the Lego bricks we have
> already is their own value add.
>
> Thanks, DW.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>