XBL2: Lexical constraints on attribute values
Bjoern Hoehrmann
I had a quick look at http://www.mozilla.org/projects/xbl/xbl2.html to
see whether it fully defines when any given attribute value conforms to
the specification. In most cases the draft is unclear or does not define
such constraints at all. This makes it rather difficult to construct any
kind of quality assurance tools for XBL2. My findings in detail below:
xbl/@script-type
xbl/@style-type
The definition refers to "MIME type". That does not tell me whether
"video" is a proper value, or "example/example;example=example" for
that matter.
binding/@element
content/@includes
Well, these are probably good enough.
template/@apply-author-sheets
template/@allow-selectors-through
content/@apply-binding-sheets
content/@locked
'true' or 'false', but it's not really clear to me whether, say,
'true ' counts as 'true' - it would in many other specifications.
This problem applies to many attributes in the draft.
That these do not accept 'yes' and 'no' strikes me as bad design.
*/@xbl:inherits
I haven't looked at this in detail.
*/@xbl:pseudo
I started a comment on the two sections that defines this attribute
the other day. After the third page I resurrected my guide on how
not to write specifications and added a bunch of examples. I do not
know which, if any, lexical restrictions might apply here.
div/@class
Sounds like any string goes, but that's far from clear.
div/@state
div/@title
These are pretty clear.
handler/@event
There are no constraints specified. This must disallow the colon so
long as XBL 2 is incompatible with namespaced events, and presumably
should inherit the lexical requirements for event local names as per
the latest DOM events specification.
handler/@phase
Not allowing at-target, capturing, and bubbling strikes me as bad
design, but, except for the general remarks discussed above, the
definition seems clear.
handler/@trusted
As for the other boolean attributes, except that 'yes' and 'no' do
not make that much sense here.
handler/@propagate
Here things get incredibly confusing, with the definition containing
a link to itself, and then having lexical constraints defined in the
processing model section. The definition seems to be there though.
handler/@default-action
The lexical space is relatively clear, but the values are rather mis-
leading. default-action='perform' does not cause the default action
to be performed, it just doesn't cancel it. I would call the attribute
prevent-default = yes | no...
handler/@button
handler/@click-count
These lack lexical constraints (and it says it's a space-separated
list despite space-separated lists being no space-separated lists!)
For example, to me, the string "2E1" matches the integer 20 as
exactly as would "2.0" and "2".
handler/@modifiers
I did not read these parts of the draft in detail yet.
handler/@key
No lexical constraints specified.
handler/@key-location
This is relatively clear.
handler/@text
I suppose any string goes.
handler/@prev-value
handler/@new-value
I suppose any string goes.
handler/@attr-name
I would assume that the value must be such that a conforming DOM
Events implementation could generate an event object with the
attrName attribute set to this value, but the draft does not say.
handler/@attr-change
This is relatively clear.
style/@media
The draft just has "How the value of this attribute is interpreted
is defined by Media Queries [MQ]." That does not imply any lexical
constraints for me.
binding/@extends
imlementation/@src
style/@src
prefetch/@src
script/@src
I guess I don't need to comment on those so long as they prohibit
non-ASCII characters.
*/@id
It is not clear what the lexical restrictions are; while the draft
says the attribute is of type ID and the XML 1.0 Recommendation says
such attributes must match the Name production given in the document,
there are several other ways to read the document, including:
* The requirement of XML 1.0 applies only to DTD validity, not
to arbitrary attributes of type ID
* In an XML 1.1 XBL 2 document, the XML 1.1 Name production is
used.
* The two Namespaces in XML Recommendations modify the Name pro-
duction to exclude the colon character, and for some reason
XBL 2 inherits this requirement.
So this needs a more precise definition.
regards,
--
Björn Höhrmann · mailto:bjo...@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/
Ian Hickson
>
> I had a quick look at http://www.mozilla.org/projects/xbl/xbl2.html to
> see whether it fully defines when any given attribute value conforms to
> the specification. In most cases the draft is unclear or does not define
> such constraints at all. This makes it rather difficult to construct any
> kind of quality assurance tools for XBL2. My findings in detail below:
>
> xbl/@script-type
> xbl/@style-type
>
> The definition refers to "MIME type". That does not tell me whether
> "video" is a proper value, or "example/example;example=example" for
> that matter.
Fixed.
> template/@apply-author-sheets
> template/@allow-selectors-through
> content/@apply-binding-sheets
> content/@locked
>
> 'true' or 'false', but it's not really clear to me whether, say,
> 'true ' counts as 'true' - it would in many other specifications.
> This problem applies to many attributes in the draft.
Fixed.
> That these do not accept 'yes' and 'no' strikes me as bad design.
It was felt better to reduce confusion and make implementation mildly
easier by not having synonyms.
> */@xbl:pseudo
>
> I started a comment on the two sections that defines this attribute
> the other day. After the third page I resurrected my guide on how
> not to write specifications and added a bunch of examples. I do not
> know which, if any, lexical restrictions might apply here.
Not knowing what problems you are referring to, I can't really fix this.
The spec seems pretty clear to me -- it has to be a valid pseudo-element
name, and the values are listed as being "value", "choices", "label",
"repeat-item", and "icon". I've tried to make minor typographic changes to
help, but I doubt it will make any difference.
> div/@class
>
> Sounds like any string goes, but that's far from clear.
Could you suggest some text that would clarify this? Any value is indeed
fair game (since the parsing of space-separated values doesn't have any
"in error" case) but I can't really see how to make that explicit without
it sounding really stilted.
> handler/@event
>
> There are no constraints specified. This must disallow the colon so
> long as XBL 2 is incompatible with namespaced events, and presumably
> should inherit the lexical requirements for event local names as per
> the latest DOM events specification.
As the editor of the DOM events specification, could you suggest text that
would be appropriate here? "The value of the event attribute must..."?
> handler/@phase
>
> Not allowing at-target, capturing, and bubbling strikes me as bad
> design, but, except for the general remarks discussed above, the
> definition seems clear.
This could be changed, what's are the preferred keywords? Why are the
longer "at-target", "capturing", and "bubbling" values better?
> handler/@propagate
>
> Here things get incredibly confusing, with the definition containing
> a link to itself, and then having lexical constraints defined in the
> processing model section. The definition seems to be there though.
Fixed.
> handler/@default-action
>
> The lexical space is relatively clear, but the values are rather mis-
> leading. default-action='perform' does not cause the default action
> to be performed, it just doesn't cancel it. I would call the attribute
> prevent-default = yes | no...
> handler/@button
> handler/@click-count
>
> These lack lexical constraints (and it says it's a space-separated
> list despite space-separated lists being no space-separated lists!)
> For example, to me, the string "2E1" matches the integer 20 as
> exactly as would "2.0" and "2".
Fixed.
> handler/@key
>
> No lexical constraints specified.
Fixed.
> handler/@key-location
>
> This is relatively clear.
Made clearer, hopefully.
> handler/@text
>
> I suppose any string goes.
Made explicit.
> handler/@prev-value
> handler/@new-value
>
> I suppose any string goes.
Made explicit.
> handler/@attr-name
>
> I would assume that the value must be such that a conforming DOM
> Events implementation could generate an event object with the
> attrName attribute set to this value, but the draft does not say.
Any string is allowed. (DOM Events and XBL could be applied to DOMs that
have attribute names that aren't valid in XML, e.g., so we can't really
restrict what is allowed here).
> handler/@attr-change
>
> This is relatively clear.
Made clearer as with key-location.
> style/@media
>
> The draft just has "How the value of this attribute is interpreted
> is defined by Media Queries [MQ]." That does not imply any lexical
> constraints for me.
Fixed.
> binding/@extends
> imlementation/@src
> style/@src
> prefetch/@src
> script/@src
>
> I guess I don't need to comment on those so long as they prohibit
> non-ASCII characters.
Why should they prohibit non-ASCII characters? Made explicit that URI
attributes are either IRIs or URIs and referenced the relevant RFCs.
There's some sort of encoding issue that this leaves undefined, IIRC, if
you could remind me of what that is and how I should fix it (assuming it's
not just a bug in RFC3987) then that would be great.
> */@id
>
> It is not clear what the lexical restrictions are; while the draft
> says the attribute is of type ID and the XML 1.0 Recommendation says
> such attributes must match the Name production given in the document,
> there are several other ways to read the document, including:
>
> * The requirement of XML 1.0 applies only to DTD validity, not
> to arbitrary attributes of type ID
>
> * In an XML 1.1 XBL 2 document, the XML 1.1 Name production is
> used.
>
> * The two Namespaces in XML Recommendations modify the Name pro-
> duction to exclude the colon character, and for some reason
> XBL 2 inherits this requirement.
>
> So this needs a more precise definition.
Fixed.
Thanks!
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'