W3C home > Mailing lists > Public > public-xhtml2@w3.org > September 2008

Re: XSD 1.1: ancestors and <input>

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Wed, 10 Sep 2008 13:41:05 +0100
Message-ID: <ed77aa9f0809100541m13de7522nfbc424f3e1b8f83b@mail.gmail.com>
To: "Steven Pemberton" <steven.pemberton@cwi.nl>
Cc: "XHTML WG" <public-xhtml2@w3.org>, "Forms WG" <public-forms@w3.org>

Hi Steven,

I missed this email up until now, I'm afraid, so I didn't include this
in my brief comments on XML Schema 1.1.

Anyway, I would suggest that this is not a problem for us, since if
you really want to enforce that an input can only go in a form
element, there are other ways to do it (namely don't place it at the
'top level' of the schema definition).

I personally think that using lots of assertions like this to maintain
schema rules could lead to schemas that are very difficult to
maintain.

Sorry...I mean, _even more_ difficult to maintain. :)

Regards,

Mark

On Wed, Aug 27, 2008 at 11:00 AM, Steven Pemberton
<steven.pemberton@cwi.nl> wrote:
>
> Group, (cc'd to Forms WG as interesting, and related)
>
> We have an outstanding review of XSD 1.1 due, but I have been asked for our
> opinion on a particular facet:
>
> XSD 1.1 adds assertions to its repertoire:
>
>  <simpleType name="string.8">
>   <restriction base="string">
>    <assert test="string-length($value) mod 8 = 0"/>
>   </restriction>
>  </simpleType>
>
>  <complexType name="even-dozens">
>   <assert test="count(*) mod 12 = 0"/>
>  </complexType>
>
> However, it only allows such assertions to refer to the element and its
> children, not to ancestors (I haven't fully understood why yet).
>
> However, there are use cases where if you want to specify the true
> restrictions on an element, you need to refer to its ancestors. And it
> happens that the (X)HTML <input> element is the poster child of such
> restrictions: it must be the child of a <form> element.
>
> There have been tricks suggested that allow you to fake the restriction,
> such as testing this on <body>:
>
>  count(.//input) = count(.//form//input)
>
> but you can't put this test where it needs to be, namely in the module that
> defines <input> (and really, it is a trick).
>
> The question that has been put to us is, can we live with this, or do we
> object?
>
> I have put it on the agenda for this afternoon.
>
> Steven
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Wednesday, 10 September 2008 12:41:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:49 GMT