[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink and XForms
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/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|