Hi Roger,
   I think, xs:error is an useful facility. Basically, if an element
or an attribute has a type xs:error, then that element or attribute
becomes invalid during validation process.
xs:error has an empty lexical and value space. It just designates,
that something is invalid.

We can utilize this behaviour of xs:error type (i.e., the component to
which it is assigned, becomes invalid), for example in CTA, as you
illustrated with a good example.

For the following attribute definition you gave:
<attribute name="kind" type="string" />

If this attribute has to be reused in multiple places, and in
different contexts, and CTA is one of them, then in CTA we can use the
type, xs:error to enforce the following constraint:
<xs:alternative test="(@kind ne 'book') and (@kind ne 'magazine')"
                    type="xs:error" />

I think, this is a very good example why xs:error is needed in 1.1 Schemas.

The enumeration way of defining the attribute, allows us to achieve,
the same validation objective, without specifying an xs:error in CTA.
I think, you illustrated this nicely in your examples.

But defining an attribute with enumeration, makes it less reusable
(for example, where, <attribute name="kind" type="string" /> might be
required).

On Wed, Jul 22, 2009 at 5:07 PM, Costello, Roger L.<costello@m...> wrote:
>
> 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



-- 
Regards,
Mukul Gandhi