RE: [regrep] V3 Proposal: Namespace Manager Function

[David RR Webber - XMLGlobal <Gnosis_@compuserve.com>]

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.