Re: [XBL] XBL 2.0 Expected context, Expected children

* Ian Hickson wrote:
>Well, for instance, how do you express the syntactic requirements for the 
>"includes" attribute? (i.e. that it must contain a syntactically valid 
>Selector?)

http://www.w3.org/TR/2006/WD-xbl-20060907/ does not appear to contain
this requirement, and if it does, I would probably not understand what
it means for a string to be an invalid selector; neither the XBL2 draft
nor the css3-selectors draft discuss this. The latter just notes

  Invalidity is caused by a parsing error, e.g. an unrecognized token
  or a token which is not allowed at the current parsing point.

which I do not really understand, and it lists some special cases. I
got the impression that the XBL2 draft at best states what is a valid
selector depends on the level of selector support the implementation
has, and that if, say, CSS Level 4 introduces a new combinator, it is
not possible to use this selector in XBL2. But this is just guessing.

Regardless, if you can devise an algorithm that determines, given a
string, whether that string is a "valid selector", then it is trivial
to encode this in e.g. RelaxNG by means of a dedicated type library,
possibly defined using DTLL.

>Or, at the element level, how do you express the content model of the 
><template> element, which says that its descendants can include <content> 
>and <inherited>, that <content> elements can't be nested (even 
>indirectly), but that those elements may not be somewhere that isn't a 
><template>, and that also allows a couple of XBL global attributes on any 
>descendant of <template> that isn't in the XBL namespace?

My understanding is that the content model of <template> is "Anything."
This is very easy to model in RelaxNG. You list three forbidden paths,

  //xbl2:content//xbl2:content
  //xbl2:content[not(ancestor::xbl2:template)]
  //xbl2:inherited[not(ancestor::xbl2:template)]

Schematron can easily express these constraints. As for the global XBL
attributes, the only structural requirement that I could find is that
for xbl:inherits and xbl:pseudo "there must be a correct template
element somewhere in the ancestor chain." This requirement is expressed
as "Expected element". The draft does not define what this means, and
attributes do not have any ancestors in the DOM, however, I assume this
just means the following paths are forbidden:

  //@xbl2:inherits[not(ancestor::xbl2:template)]
  //@xbl2:pseudo[not(ancestor::xbl2:template)]

Again, Schematron can easily express this. This does not express that
the <template> element is "correct", but this requirement seems highly
redundant with the assumed requirement that any and all <template>
elements must be correct anyway.

So this leaves us with indirectly nested <content> elements. I am not
sure how you'd achieve indirectly nested <content> elements, I just
found a typo in "If T contains a correct and content element", so I
leave this out here. Presumably, how easy to detect this problems is
will depend on how much effort is required to turn the indirect re-
lationship into a direct one.

>Or, hwo do you express the content model of the <script> element, given 
>that it is dependent on the script-type="" attribute on the <xbl> element?

There is again no difficulty here, except for those that are inherent
to the conformance definition in the first place. I would not impose
such restrictions, however.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 13 October 2006 23:17:00 UTC