Re: [xforms] global attributes

Micah Dubinko wrote:
> Hi Anne. Wouldn't defining these things at the XForms level cause *more* 
> problems?

I don't think they do.


>> The problem is that the specification is currently underspecified. It 
>> is unclear what the host language is and what kind of CLASS attribute 
>> it may introduce. It is also unclear what other attributes it may 
>> introduce.
>
> Should XForms actually define chunks of the host language, or merely set 
> up requirements for the host language to fulfill?

That would be possible. However, the section we are talking about now 
would need to be rewritten from a non-normative note to something normative.

The problem is that you can have support for multiple host languages 
that define all different things XForms should support. You are simply 
not going to sniff the document to see what namespaces are used and 
change the content model of your XForms implementation accordingly. 
Instead, you support a set of attributes throughout elements in the 
XForms namespace.



> For example, CSS is not required at all by XForms (or XHTML). True, 
> certain things need to operate in certain ways, but no actual CSS 
> support is mandated. So it is fully the job of the host language to 
> define 1) what level of CSS support it includes, and 2) what markup 
> holds the CSS content.
> 
>> For example, while XHTML and SVG have a CLASS attribute defined as a 
>> space-separated list of strings, FooML might have a similar CLASS 
>> attribute that has a comma-separated list strings.
>
> I see this as a good argument for not defining it in XForms!

I think it is.


> What you might be arguing for, in the specific case of CSS, is a 
> universally recognized attribute named, say 'class' (or css:class if you 
> can stomach the namespaces) that has a well-defined relationship to CSS.

Perhaps, but I think the arguments made about CLASS and other attributes 
that might be defined global apply to the accessibility attributes as well.

(Perhaps it would be useful to have a specification that defines CLASS 
and let SVG, XHTML 2.0, XForms x and others refer to that specification 
for inclusion of it. So they are all using the same attribute.)


>> What if I mix XHTML, XForms and FooML? Does XForms get two CLASS 
>> attributes?
> 
> To mix languages, you'd need to define a profile. The profile will say 
> how CSS gets used, and what attributes contain the classes, etc. If 
> XForms said 'thou shalt use class', there's be an irreconcilable 
> conflict in your scenario above.

I don't think browsers are going to implement every profile around and 
switch their implementations when they have sniffed a particular 
profile. The idea is nice in theory, but implementations are more likely 
to deal with undefined profiles on the web. Say XForms 1.0 + XHTML 1.0 + 
MathML 1.0.

XForms should be a language that can be mixed with other XML 
vocabularies without setting requirements for those languages. It should 
also include basic accessibility attributes so the language itself is 
actually accessible and it doesn't depend on the host language for that.


>> So as suggested above, I think XForms should specify a set of global 
>> attributes rather than leaving that up to the host language. Since it 
>> is unclear what the host language is and it is even more unclear what 
>> should happen when there are multiple languages that could be the host 
>> language that introduce the same attribute with a different syntax, 
>> but similar semantic value.
> 
> For xml:lang and (soon, hopefully) xml:id, it already is the case (and 
> you wouldn't want such general-purpose stuff defined in a forms spec 
> anyway). For class, I'm pretty sure it's been discussed before, but as a 
> personal observation, it's never hit a pain point hard enough to get a 
> change through the system.

I think you want to have them in some XML Schema. That XForms 
acknowledge they are allowed.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

Received on Friday, 11 March 2005 08:43:14 UTC