Re: Question about xs:anyAttribute and xs:any

"David Kruppke" <kruppke@gefeg.com> writes:

> If I understand the rules right then it is possible to have more than one
> attribute in the inherit type that matches the namespace requirements of one
> xs:anyAttribute in the base type.

Correct.

> But as I understand it is different for xs:any. I interpret the rules so
> that I can only replace the xs:any with one xs:element. If I want to have
> more than one I have to replace the xs:any with xs:sequence, xs:choice or
> xs:all.

Yes, as long as the xs:any has min/max appropriate to the
xs:sequence/xs:choice/xs:all

> If I try to check these conditions using the newest XERCES, it allows me to
> replace one xs:any with more than one elements (depending on minOccurs and
> maxOccurs).

_If_ I've understood the question, I _think_ this shouldn't be
allowed.

That is, if you are saying that 

Base:  (a, any*, b)
Restr: (a, x, y, b)

is allowed, I think the REC as written does not allow this, that it
should allow it (supposing x and y are namespace-compatible with the
wildcard), and that current plans for version 1.1 of XML Schema, as
signalled in the first PWD thereof, _will_ allow it.

Furthermore, as frequently mentioned here, because one of XSV's
purposes is a test bench for the REC editors, it already implements
1.1 in this area, and _should_ allow it.

Don't know what Xerces says about its behaviour here.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]