RE: [cam] Variable Names

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Martin,

This is excellent news.   When I did the original work on this - I 
was basing it on XPath V1.0 - and the W3C spec' which is 
painful to read and make sense of at best.   I also pinged
a couple of Xpath gurus - but got no helpful feedback - but
at least they did not contest my findings.   So I responded
with the business extensions.

It appears that other people have gone ahead of us and
extended the XPath accordingly.

I agree - since its already there - let's adopt it.

I guess we'll uncermoniously dump the syntax I came
up with if noone has any objections?  I don't see any
value in having one, and a second as optional - that
would just be a potential incompatiblity issue.  Let 
me know otherwise if people want to suggest another
option - otherwise I'll assume this works for people.

BTW - I'm compiling the list here of changes and edits 
for the next 0.14 revision, and as with the 0.13 revision, 
will send out the full set and let people review and have
a chance to comment.

Hopefully though this whole process of clean-up and
syntax enhancement is details here - since the overall
functionality and purpose is retained - and thats the key.

At this point of the game these changes are cheap.  Once
we have our first official public release of course - then we'll 
be wanting to have it stable - and getting there is what this
part of the process is about.

I don't know what's worse - writing code to test and validate
the spec's - or being editor and having to make all the edits,
updates, and changes afterwards!

Thanks, DW.
=======================================================
Message text written by INTERNET:martin.me.roberts@bt.com
> 
Further investigation shows the following would be possible but different
if
we used native xpath to resolve these conditions:
 
    equal  would be come => $variable = 'testValue'
    NOTequal(value,'value') => not(value1,'value')
    greaterthan(v,v) => value > value
    lessthan(v,v) => value < value or value &lt; value
    greaterthanEQ => value >= value
    lessthanEQ => value <= value or value &lt;= value
    begins => starts-with(value,value)
    ends => ends-with(value,value)
    contains => as stated
 
    We would also get for free string-length(), count() etc...  plus we get
someone else to do the exception management.
 
    I personally am all for not reinventing things.  The problem would be
lookup() and member() but looking at the code it should be possible to
extend the function sets supported by Jaxen.  There is a minor bug in jaxen
and this is that the id() function does not seem to work.  Minor problem.

<