OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] XForms Annotations (was Annotations in XPath-NG?)

[ Lists Home | Date Index | Thread Index ]

So, I'm answering with an XForms hat on (though still personal opinion). I
realize there are broader issues in the over XPath-NG arena, but I'm just
focusing on the XForms-specific ones here.

Uche Ogbuji wrote:
>In the general case, we seem to have two candidates: accessor functions and

>special axes.  Which one would you think works best with the XForms model 
>properties?

Well, the hard part about planning for the future is that you don't know how
it will turn out!

One thing that would be desirable is backward compatibility, or at least
graceful failure, when XForms-NG documents hit an XForms 1.0 processor.

XForms does have a function called property(), which is extremely limited in
XForms 1.0, but will likely be expanded upon in a later version.

There's also a function if(test,tval,fval) (yes, a function, because adding
a statement on top of XPath 1.0 wouldn't fly). Because of not having side
effects, there's no short-circuit evaluation for if().

So a form could have an expression like this:

if( property('relevant'), property('relevant'), value_for_false )

which would return the value of the property 'relevant' on the context node,
or value_for_false in XForms 1.0. Hmm, for better future compatibility,
maybe property() should accept an optional node to get properties against...

But something like this wouldn't work:

if ( a/b/c/property::relevant, ...

Because it would be a syntax error to XPath 1.0 and foul up form processing.

Anyway, I do think an axis-based solution might be a little cleaner. Would
you see any problems if XForms-NG mapped the axis traversal to the
property() function?

>My question above is more, if backward compat wasn't an issue, which way 
would you lean?

I decline to directly answer, because I think backwards compatibility will
be important enough to affect the decision. :-)

Thanks,

.micah

-----Original Message-----
From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]
Sent: Wednesday, October 09, 2002 2:50 PM
To: Micah Dubinko
Cc: Jeni Tennison; Eric van der Vlist; xml-dev@lists.xml.org
Subject: Re: [xml-dev] XForms Annotations (was Annotations in XPath-NG?)



> I've been meaning to post something like this to xml-dev for awhile, now.
> 
> XForms is probably a good data point to look at for XPath annotations, if
> I'm not misunderstanding the discussion.
> 
> XForms is fully an XPath spec; brethren to XSLT and XPointer. As for
> annotations, XForms defines "model item properties" [1], such as
"required",
> "relevant", "readonly", etc., which attach to the XPath 1.0 data model on
a
> per-node basis. Form controls, which also attach to a particular node,
alter
> their behavior based on the model item properties (which so far can all be
> represented as strings) at that node.
> 
> >From an implementation standpoint, it would be nice to have a way to
attach
> these extra properties to nodes.

The idea itself is similar to what we've been discussing here.  I don't
think 
the binding mechanism defined in XForms is really suitable, since a general 
XPath processor would not add anything to the source document, nor is there 
really any place in the dat model for the bind elements themselves.

I also don't see in th XForms spec a mechanism for accessing bound
properties. 
 Perhaps this is what leads to your next para...


> >From a standardization standpoint, it would be nice if XPath 2.0 included
a
> way to access these properties. (We avoided defining accessor functions in
> XForms 1.0 because there are some non-trivial complications that can crop
> up, related to self-referential calculations, but that's firmly an XForms
> problem to solve)

In the general case, we seem to have two candidates: accessor functions and 
special axes.  Which one would you think works best with the XForms model 
properties?


> We were mainly looking a function-based access, though I suspect that's
just
> because extension functions are easier to plug into an existing
> implementation (compared to, say, a new axis)

Yes.  My question above is more, if backward compat wasn't an issue, which
way 
would you lean?


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Apache 2.0 API -
http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML -
http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib -
http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS