[
Lists Home |
Date Index |
Thread Index
]
Hi Joerg,
Hrm... I quite liked the XPath support in XForms, so I'm curious as to
why you don't like it...
> Sebastian Schnitzenbaumer wrote:
>> Well, how would you have done it?
> What do you mean?
> Ah, probably:
> > ...XPath for references within XForm
> (In ancient times, people quoted the statements they
> answered to immediately above the answer.)
>
> Well, there are still IDs which can be used for
> references within the same document, or, slightly more
> general, names. An XPath can be seen as a "natural implied
> name", nevertheless, the problems I have with this
> choice:
> - It increases the pressure on XSLT processor implementations
> to provide functionality to dynamically evaluate XPaths
> coming from the input XML. Having such a function enabled
> is a potential security risk, and does not fit all that
> well with XSLT compilers (and renders all the work of the
> WG to keep XSLT easily compilable moot).
It sounds as though you're assuming that XForms processors will be
XSLT stylesheets, and that you're objecting to the XForms design on
that basis. It's certainly true that if you're transforming XForms to
HTML you need to evaluate XPaths in order to fill in default values,
to check whether particular fields are read only or required and so
on.
However, I was under the impression that XForms would be processed by
dedicated processors, probably built into browsers. For example, the
XForms processor in XSmiles isn't built on the basis of transforming
the XForm document using XSLT. So objecting to the XForms design on
the basis of what it may or may not be necessary for XSLT to then
support seems a little weird.
In addition, it's perfectly possible (as usual) to get around the
desire for dynamic evaluation using a two-step transformation, the
first generating a stylesheet that then gets used to generate the
final result. The XSL WG have successfully managed to resist the call
for dynamic evaluation in XSLT thus far, despite great demand. I don't
really think you can blame XForms for that demand; it's coming from
ordinary users with home-brew XML that uses XPaths internally.
Also, since XForms are dynamic, I'm not convinced that the evaluation
should be done at transform time (if you are using XSLT to transform
an XForm into HTML). You're going to need to do all the
checking/calculation through client-side scripts anyway (I think) to
get the dynamic form behaviour correct, so it makes more sense to
shift all that evaluation out of the XSLT and into the client.
Finally, while I can see that IDs and names could be used to identify
elements within the instance, you'd still need an expression language
to make assessments such as whether a field should be read-only,
whether required or not or what its calculated value should be. Would
you prefer XForms to make up their own expression language? Or prefer
that they provide the option for users to use
JavaScript/JScript/Python/Perl/whatever scripting language they
prefer?
> - It is more of a burden for XForm writers than it may look
> at a first glance. If there are inserts or rearrangements
> of the data elements, every reference has to be checked and
> perhaps changed. This pretty much requires tool support
> for editing of not-quite-trivial forms. If they used IDs
> or names, this is not a problem.
From what I can tell, it's perfectly possible for XForm authors to use
IDs to identify particular elements in the instance if they want to,
and then use the id() function to refer to them. Perhaps it would be
beneficial to encourage authors to do so as best practice to ease
maintenance. Another best practice might be to use relative XPaths
rather than absolute ones -- at least that means that if you change
the structure of your instance data you only have to change the
relevant references, not every single one.
But in some situations, I imagine that adding IDs to every element in
the instance data is impossible. For example, if the instance data
itself is extended due to repeated structures then those new elements
would have to have their own identifiers, which won't be known at
design time. Also, of course, you can't attach IDs to attributes;
perhaps you had some formulaic way of naming them in mind? Or perhaps
you were talking about IDs in a more generic way rather than
specifically XML IDs?
I feel like I must be missing something...
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
