Re: XSD validation, ambiguous root XML instance element

Thanks, for a detailed explanation about this topic.

That's helpful.

On Thu, Nov 5, 2020 at 8:31 PM C. M. Sperberg-McQueen <
cmsmcq@blackmesatech.com> wrote:

>
> > On 4,Nov2020, at 10:53 PM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
> >
> >
> > Hi all,
> >     With respect to the discussion currently going on within this
> thread, I'd like to share following thoughts about XSD (broken into 2 cases
> A & B),
> >
> > (A)
> >
> > Let's say that, following is a given XSD document (and this is the only
> XSD document, that available for an XML document validation),
> >
> > <?xml version="1.0"?>
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> >
> >      <xs:element name="m"/>
> >
> >      <xs:element name="n"/>
> >
> > </xs:schema>
> >
> > According to above mentioned XSD document, following two XML instance
> documents would be valid,
> >
> > 1)
> > <m/>
> >
> > 2)
> > <n/>
>
> Yes and no.  That is, under some circumstances what you say is true, and
> under some circumstances it is false.
>
> It is a consequence of the way schema-validity assessment is defined in
> the spec that the validation result on the two documents you give depends
> not just on the document and the schema but also on the node chosen as the
> validation root, , on the validation approach, and (for some approaches)
> the declaration or definition stipulated as applicable to the validation
> root.
>
> For simplicity, I assume in what follows that the outermost element in the
> document is chosen as the validation root.
>
> For type-driven validation with xsd:anyType or with xsd:string or with any
> simple type for which the empty string is in the lexical space of the type,
> both 1 and 2 have [validity] = valid and [validation attempted] = full.
>
> For type-driven validation with other types in the schema (e.g. xsd:date),
> both 1 and 2 have have [validity] = invalid and [validation attempted] =
> full.
>
> For element-driven validation using the element declaration for element
> ‘m’, both 1 and 2 have [validation attempted] = full, 1 has [validity] =
> valid, and 2 has [validity] = invalid.  For element-driven validation using
> the element declaration for element ’n’, 1 is invalid and 2 is valid, and
> in both cases [validity attempted] = full.
>
> For attribute-driven validation using any of the built-in declaration for
> xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation,
> neither 1 nor 2 is valid (no element is valid against an attribute
> declaration).  Both elements will have [validation attempted] = full and
> [validity] = invalid.
>
> For lax wildcard validation and strict wildcard validation, both documents
> will have [validity] = valid, [validation attempted] = full.
>
> You don’t consider the case of a document of the form
>
>     <p/>
>
> but it may be worth considering.  Its behavior for type-driven and
> attribute-driven validation is as for <m/> and <n/> and it will be invalid
> against either element declaration in the schema.  For lax wildcard
> validation it will have [validation attempted] = none and [validity] =
> notKnown.  For strict wildcard validation, the results will be the same as
> for lax wildcard validation; the difference in terminology expresses only a
> difference in the expectations of the person or process invoking
> validation: the term ‘lax wildcard validation’ suggests that a [validity]
> value of valid or notKnown is acceptable, while a value of invalid is not
> acceptable, while ’strict wildcard validation’ suggests that [validity] =
> notKnown is not acceptable to the caller.
>
> >
> > (B)
> >
> > And, if following is an XSD document (and this is the only XSD document,
> that available for an XML document validation),
> >
> > <?xml version="1.0"?>
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> >
> >      <xs:element name="m"/>
> >
> > </xs:schema>
> >
> > following is the only XML instance document (its my personal choice, to
> ignore XML child elements and attributes), that would be valid according to
> above mentioned XSD document,
> >
> > <m/>
> >
> > The XSD case (B) above, effectively makes a constraint that, XML element
> name "m" can be the only XML instance document root element name.
> >
> > The XSD case (A) mentioned above, allows for both "m" and "n" to be
> valid XML instance document root element names.
>
> You seem to be assuming that the processor performs lax (or strict)
> wildcard validation starting at the outermost element of a document. There
> are processors which do so by default; there may be processors which cannot
> be invoked any other way.  But that is a property of the processor, not of
> XSD schemas or XSD schema validity assessment.
>
> My apologies for the profusion of technical detail here.  I think a case
> could be made that XSD would be more usable if the spec had provided a
> default meaning for the phrase “document D is valid/invalid/undecided
> against schema S”, since that is what many (perhaps most) users of any
> schema technology will want to say about their documents and schemas.  It
> has not been helpful to require, as the XSD spec does, that any meaningful
> statement about the schema validity of a document specify the validation
> approach, the validation root, and in some cases also the stipulated type
> definition, element declaration, or  attribute declaration.
>




-- 
Regards,
Mukul Gandhi