Re: [xml-dev] ID Conflicts in Namespaces.

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

I agree that it's an error, but what about in the context of usage of
xsi:schemaLocation?
Specifying two different schemas for different namespaces?

Or in contexts where the validation is built up by the application
having a library of schemas that do not reference each other
associated with the various namespaces.

suppose:


<document xmlns:one="http://www.example.com/document";
xmlns:two="http://www.sample.com/sample";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
         xsi:schemaLocation="http://www.sample.com/sample
http://www.sample.com/sample/sample.xsd
http://www.example.com/document
http://www.example.com/document/document.xsd";
>
       <one:paragraph id="one">This is a sample paragraph.</one:paragraph>
       <two:text id="one">This is another sample paragraph.</two:text>
</document>

At this point I suppose the validation root is still the document
element, validated laxly (dependent on parser) but I feel
uncomfortable about it. As if this matter were underspecified for me.

Cheers,
Bryan Rasmussen


On 8/18/06, Michael Kay <mike@saxonica.com> wrote:
> >          Thanks for the response. I tried to dig up that
> > information in various specs, and couldn't find anything
> > (which may speak more to my spec-reading abilities than
> > anything, but there you go.)
> >
> >          Where are you drawing your information from?
>
> You start to understand the XML Schema Part 1 spec on about the fifth
> reading, if you can stay awake and concentrate.
>
> Section 2.1 starts:
>
> An XML Schema consists of components such as type definitions and element
> declarations. These can be used to assess the validity of well-formed
> element and attribute information items (as defined in [XML-Infoset]), and
> furthermore may specify augmentations to those items and their descendants.
>
> Section 4.1 explains:
>
> [Validity] .assessment. is defined with reference to an .XML Schema. (note
> not a .schema document.) which consists of (at a minimum) the set of schema
> components (definitions and declarations) required for that .assessment..
>
> In other words, you assemble a schema from a set of schema components which
> may or may not originate from a set of schema documents, and you use this
> set of schema components to perform validation.
>
> The specific rules for ID/IDREF are described in:
>
> Validation Rule: Validation Root Valid (ID/IDREF)
> For an element information item which is the .validation root. to be .valid.
> all of the following must be true:
> 1 There must be no ID/IDREF binding in the item's [ID/IDREF table] whose
> [binding] is the empty set.
> 2 There must be no ID/IDREF binding in the item's [ID/IDREF table] whose
> [binding] has more than one member.
>
> For this you need to understand the way the ID/IDREF table work; but in
> priciple it's simple: if an element or attribute is validated as an instance
> of xs:ID then it is added to the table. There's only one such table for a
> validation episode, so it's irrelevant where the constraints were defined.
>
> Michael Kay
> http://www.saxonica.com/
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>