- From: Costello, Roger L. <costello@mitre.org>
- Date: Wed, 22 Jul 2009 07:37:58 -0400
- To: "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
Hi Mukul, Yesterday I was talking with a colleague and I described to him Conditional Type Alternative (CTA) and then xs:error. He was puzzled about xs:error. He couldn't see a legitimate (nonredundant) use case for it. As I got to thinking about it, I agreed with him. For example, if the kind attribute is declared like this: <attribute name="kind"> <simpleType> <restriction base="string"> <enumeration value="book" /> <enumeration value="magazine" /> </restriction> </simpleType> </attribute> Then this CTA will ensure that <Publication> has MagazineType content when kind equals 'magazine' and <Publication> has BookType when kind equals 'book' and an error is generated when kind has some other value: <xs:element name="Publication" type="PublicationType"> <xs:alternative test="@kind eq 'magazine'" type="MagazineType" /> <xs:alternative test="@kind eq 'book'" type="BookType" /> </xs:element> If the kind attribute is declared like this: <attribute name="kind" type="string" /> Then this CTA does the same functionality as above: <xs:element name="Publication" type="PublicationType"> <xs:alternative test="@kind eq 'magazine'" type="MagazineType" /> <xs:alternative test="@kind eq 'book'" type="BookType" /> <xs:alternative test="(@kind ne 'book') and (@kind ne 'magazine')" type="xs:error" /> </xs:element> In this case xs:error is used to trigger an error when kind does not have the value 'magazine' or 'book'. Thus, this shows two ways to do the same thing. Is that the purpose of xs:error, to provide another way of accomplishing things? That's okay, but it shows xs:error as being redundant. Is there some example that shows xs:error doing something that could not otherwise be accomplished? /Roger > -----Original Message----- > From: Mukul Gandhi [mailto:gandhi.mukul@gmail.com] > Sent: Wednesday, July 22, 2009 4:45 AM > To: Costello, Roger L. > Cc: xmlschema-dev@w3.org > Subject: Re: [XML Schema 1.1] I need an example that > illustrates the usefulness of xs:error > > Hi Roger, > It's said in the XML Schema 1.1, spec that xs:error is mainly > useful in "conditional type alternative" (CTA) definitions. > > As far as I know, xs:error is a special type which is present > implicity in all 1.1 Schemas. If the xs:error type get's applied to > anything (like, element or attribute), that component becomes invalid. > > So, for the above CTA definition, if the 3rd XPath test succeeds, the > element is invalid for such data. > > I think, having something like xs:error is neccessary for type > alternatives. Because, we must be able to say, that for what > condition, an element should be invalid. > > The attribute definition, for "kind" which you have defined, describes > how "kind" should be represented. But it doesn't say, that for what > values, of "kind" the "Publication" element should have which type > (which is possible with CTA). > > On Wed, Jul 22, 2009 at 1:26 AM, Costello, Roger > L.<costello@mitre.org> wrote: > > > > Hi Folks, > > > > Consider this usage of xs:error: > > > > <xs:element name="Publication" type="PublicationType"> > > <xs:alternative test="@kind eq 'magazine'" > type="MagazineType" /> > > <xs:alternative test="@kind eq 'book'" type="BookType" /> > > <xs:alternative test="(@kind ne 'book') and (@kind ne > 'magazine')" > > type="xs:error" /> > > </xs:element> > > > > It says that if an instance document has a Publication > element with a kind attribute not equal to 'book' or > 'magazine' then throw an error. > > > > But that doesn't illustrate the usefulness of xs:error > because the same functionality can be accomplished by simply > constraining @kind: > > > > <attribute name="kind"> > > <simpleType> > > <restriction base="string"> > > <enumeration value="book" /> > > <enumeration value="magazine" /> > > </restriction> > > </simpleType> > > </attribute> > > > > Can you provide an example that illustrates the usefulness > of xs:error? > > > > /Roger > > > -- > Regards, > Mukul Gandhi >
Received on Wednesday, 22 July 2009 11:38:36 UTC