At 08:24 AM 12/3/2004, Michael Kay wrote:
> > Now I have 1 namespace = 2 different
> > schemas. A data stream that validates against schema 1 with
> > namespace=foo
> > will not validate against schema 2 with namespace=foo. A
> > substantial amount
> > may be legal because of the shared common information but the
> > upper wrapper
> > elements would immediately fail validation.
> >
> > Is there anything that considers method 2 a legal design?
> >
> > If it isn't illegal is it at least a really poor and
> > troublesome design?
> >
>
>I think there's a real contradiction in the design philosophy here.
>
>On the one hand, XML Schema recognizes that different people may want to
>apply different validation criteria to the same document at different stages
>of its lifecycle. The sender, for example, may apply stricter rules than the
>recipient. So there can be more than one schema that's applicable to a given
>document.


 >>>Exactly. I have no problem with flavors of a schema that are setup for 
different levels of validation and all of those having the same namespace. 
It might be a problem with managing the files and triggering the right file 
to be used, but that seems OK withon a namespace. I can 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 just a tool to help manage 
the real world environment where some might have a local copy and others a 
network copy and maybe several network copies for redundancy.

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



>On the other hand, XML Schema suggests that knowing the target namespace is
>enough information for a schema processor to go and find a schema, with the
>schema location being just a hint. If there is more than one schema for a
>namespace, then there is no way of telling the processor reliably which one
>you want to use.
>
>Let's hope that the WG grasps this particular nettle in its work on
>versioning.


 >>>Yes agreed. Also can we work on the existing specifications so that a 
given specification explains all the rules about using that feature. 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.

..dan



>Michael Kay
>http://www.saxonica.com/

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

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

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


     



From ekimber@i... Fri Dec 03 17:12:39 2004
Received: from bart.w3.org ([128.30.52.40])
	by frink.