W3C home > Mailing lists > Public > www-forms-editor@w3.org > March 2005

Re: [xforms] global attributes

From: Micah Dubinko <micah@dubinko.info>
Date: Thu, 10 Mar 2005 23:45:26 -0700
Message-ID: <42313E86.8060901@dubinko.info>
To: Anne van Kesteren <fora@annevankesteren.nl>
CC: www-forms-editor@w3.org

Hi Anne. Wouldn't defining these things at the XForms level cause *more* 

Anne van Kesteren wrote:

> Attributes that would be useful to have on all elements include:
>  * xml:lang
>  * xml:id
>  * class

I absolutely agree that these are useful to have around.

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

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!

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.

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

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

The Compound Documents group, which I'm not involved in, might have more 
to say.



  Available for consulting. XForms, web forms, information overload.
  Micah Dubinko                           mailto:micah@dubinko.info
  Brain Attic, L.L.C.                        http://brainattic.info
  Yahoo IM: mdubinko
  Learn XForms today: http://xformsinstitute.com
Received on Friday, 11 March 2005 06:46:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:06 UTC