Re: target namespace and namespaces

At 11:27 AM 12/3/2004, Jeff Rafter wrote:
>>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.


Can you point me to any documentation along these lines? This is "good" 
news, but it is still something that is being layered on from the outside. 
Hopefully schemas in the next release will have an official stand or 
develop their own strategy. Ultimately My organization is looking for an 
approach that is "standardized" and too them it means that there is direct 
tool support for all this.



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



 >>> I agree that distinguishing names was the goal, but this then has been 
overalyed with "location" and is one of the few ways to also detect 
versioning by a tool out of the box. This is where I wish the Namespace 
spec would come out with a definitive statment of its use and that all the 
other standards would respect that design rather than stretching it for 
their needs in other directions.



>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


 >>>I have no problem with modules being of the same namespace. Its when 
the top level objects are used differently and create new specific objects. 
These too me should always be unique.


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

 >>>That is fine as well, but the other specs shouldn't overlay their 
meaning and use on top of the Namespace spec and its definition of use. 
They need to respect the original design rather than trying to change it to 
their needs.


>All the best,
>Jeff Rafter

---------------------------------------------------------------------------
Danny Vint

Specializing in Panoramic Images of California and the West
http://www.dvint.com

voice: 510-522-4703
fax: 801-749-3229

Received on Friday, 3 December 2004 20:03:10 UTC