> also see a need for things like XML catalog that help point me to the 
> proper location of the schema across several different locations where 
> it might be installed (anyone considering this for schemas?). 

This is where RDDL and NRL rule... XML Catalog has stagnated wrt to 
Schemas in light of the various other approaches.

>  >>>What I'm being requested to do is build essentially two differtn but 
> releated schemas and assign them to the same namespace. This is for the 
> Insurance industry where we want the same message name and general 
> design, but we have different lines of business involved. So the 
> Personal Auto users don't want a schema that includes or has the 
> overhead of the Workers Comp data elements. Ultimatly the reasoning here 
> is that with the slimmer more tailored schema they are not dealing with 
> any excess parser overhead to load a schema with elements that are not 
> needed or for code generators to create class definitions for things 
> they are not going to use.

Right. This makes good sense. In the mortgage industry in the U.S. 
(MISMO) this issue has had a lot of discussion. Should there be an 
overarching mortgage namespace or should each sub-category of mortgages 
have a separate namespace (e.g. Credit Ordering, Processing, 
Servicing)-- and ultimately it looks like it will be separate namespaces 
  with shared components included a la the Chameleon approach.

The point is to keep in mind what namespaces are actually intended for-- 
distinguishing the meaning of like names. So in all of the various 
mortgage areas you have a <BORROWER> element-- but in each area it has a 
slightly different meaning: potential borrower, current borrower, and 
historical borrower could be one lens for instance. There is a lot of 
overlap, but a lot of items that are discrete (for example no one in the 
credit industry wants to see the data from the servicing side-- they are 
not interested in how the borrower's loan was sold between mortgage 
companies). This seems very analogous to your insurance problem.

With all of that said, I am very surprised by the direction of the 
discussion thus far. In the general sense I would say that there should 
be no problem with multiple schemas for a single namespace. Even if they 
are modules and not top-level. Why is this a problem? How does this 
differ from a single schema which has multiple global elements each of 
which is a candidate for the root element of an instance. The multiple 
schemas simply enlarge this list of candidate components. I understand 
how in the above examples this might be problematic-- but I would argue 
that in those circumstances you are actually overusing the domain 
similarity and should break it down further. Any system that associates 
a schema with a document should on some level translate that to a set of 
schema components, having multiple distinct sets should only aide people 
in the tasks that you mention... i.e., code generation.

> In this case the Namespace spec explaining how it should be used and 
> what it means - and then all the other specs adhere to that design.

I really hope they don't modify the namespace rec to steer the 
development of schema languages and how they are associated with various 
vocabularies... then we would have a real mess.

All the best,
Jeff Rafter

From dvint@d... Fri Dec 03 20:03:10 2004
Received: from bart.w3.org ([128.30.52.40]