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

On Sat, 14 Oct 2006, Bjoern Hoehrmann wrote:
> * 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

Fixed.


> 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.

Please raise this with the CSS working group.


> 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.

I don't see that the first part is a problem or that the second part is 
true. If you could elaborate on this, possibly explaining what parts of 
the spec you think need changing, that would be very helpful.


> 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.

Cool.


> >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."

Well, it's anything that is conformant according to the namespaces 
involved. For example, the following wouldn't be allowed:

   <xbl:template>
     <html:p><html:p></html:p></html:p>
   </xbl:template>


> 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.

(I've fixed the error you mention in passing above.)

I'm glad to hear that there are indeed various languages that can 
represent the XBL2 syntax.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 5 January 2007 01:27:37 UTC