Re: Can toggle@case or case@selected be calculated?

Thinking about this purely as a selfish form author, AVTs are one of  
those things that you find yourself wanting to use over and over  
again, especially as XForms uses XPath all over the place. It is a  
real pain not having them in XForms, and I agree 100% that if they  
are ever introduced to XForms authors will start thinking about using  
them in host languages too. After all, I can already use  
xforms:output to change element values in a host language, so why  
shouldn't I able able to use AVTs to set attribute values too?

The idea of turning attributes into elements so that their values can  
be set dynamically seems eccentric. As a general principle of XML  
markup design it seems odd to say that a good way of indicating that  
an attribute can have its value calculated dynamically is to turn  
that attribute into an element. This is especially so when the AVT  
mechanism exists and is widely used and understood.

Personally I would prefer the working group to add AVTs selectively  
rather than go down this path. Just make sure that it is clearly  
documented where AVTs are permissible. Form authors will I think much  
prefer the AVT route.

Of course there are strong aesthetic arguments for adding curly  
brackets to any mark-up language. It gives a nice baroque feel I  
think, providing effective contrast to the more severe lines of  
square brackets.

All the best

Mark

On 19 Aug 2006, at 05:03, T. V. Raman wrote:

>
>
> Further more, the trick in getting XForms right -- and this is
> what makes it non-trivial --
> is to ensure that XForms can both host and be hosted in other
> languages. So in general it doesn't make much sense for the
> XForms spec to pretend that AVTs will never show up --  basically
> if the language in which XForms is hosted supports AVTs  --- say a   
> future
> version of Open Office for instance,  then XForms will
> automatically get AVTs in it. I'm not suggesting that Open Office
> is certain to have AVTs; I'm just using it as an example.
>
>>>>>> "Erik" == Erik Bruchez <ebruchez@orbeon.com> writes:
>     Erik> Ulrich Nicolas Lissé wrote:
>     Erik>
>>> I even don't see a Pandora's box of processing questions
>>> open as John stated: It should be clearly stated when
>>> these AVTs are evaluated and in which context (like it is
>>> for any other XPath expression in XForms).
>     Erik>
>     Erik> I agree 100%, this is a non-issue. XSLT too has to
>     Erik> define exactly where AVTs can be used. Furthermore,
>     Erik> several XForms implementations already implement AVTs
>     Erik> and their authors have not reported negatively on this
>     Erik> AFAIK.
>     Erik>
>>> AVTs occurring in non-XForms-markup are not the XForms
>>> processor's cup of tea. The latter might be dissatisfying
>>> to form authors attempting to use AVTs in XHTML markup but
>>> they can't use XPath expressions there too.  So this is no
>>> point against introducing AVTs to XForms in my eyes.
>     Erik>
>     Erik> XForms could allow a host language to use AVTs, and
>     Erik> specify a processing model for those. In fact, I think
>     Erik> that XForms should do just that in 1.2 or 2.0 (AVTs
>     Erik> won't be in 1.1). It doesn't mean that host languages
>     Erik> must implement AVTs, just that they may do so. The
>     Erik> benefits of AVTs are tremendous, in particular with
>     Erik> XHTML. A typical use case is to update the @class or
>     Erik> @style attribute on an XHTML element.
>     Erik>
>     Erik> -Erik
>     Erik>
>     Erik> -- Orbeon - XForms Everywhere:
>     Erik> http://www.orbeon.com/blog/
>
> --
> Best Regards,
> --raman
>
>
> Email:  raman@users.sf.net
> WWW:    http://emacspeak.sf.net/raman/
> AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
> Google: tv+raman
> IRC:    irc://irc.freenode.net/#emacs
>

Received on Sunday, 20 August 2006 10:48:04 UTC