[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] RE: Should the XPath working group add support for animport capability?
- From: David Lee <dlee@calldei.com>
- To: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Mon, 14 Jan 2013 16:14:10 +0000
-----Original Message-----
From: Dimitre Novatchev [mailto:dnovatchev@gmail.com]
Sent: Monday, January 14, 2013 10:32 AM
To: David Lee
Cc: Costello, Roger L.; xml-dev@lists.xml.org
Subject: Re: [xml-dev] RE: Should the XPath working group add support for an import capability?
On Mon, Jan 14, 2013 at 6:45 AM, David Lee <dlee@calldei.com> wrote:
> IMHO ...
> XPath is not intended as a fully featured language but rather a common expression vocabulary.
>> Yes, there is a substantial difference in what XPath was intended to
>> be and what XPath 3.0 actually is.
"Actually Is" is subjective.
Once something starts being used for cases it was not intended then wonderful things start happening.
>> Roger's recent work shows that one
>> can have useful libraries of XPath - defined functions, that are
>> independent of any host language and thus fully portable across host
>> languages.
Disagree. Without the ability to define *named* functions such a library is not directly usable by itself.
You need further code to make use of it. In fact you need Language of some sort to wrap these things and name them and execute them.
>> And complete XPath applications (programs) are also
>> possible.
To the extent that they are possible yes ...
I could have a "library" of C expressions but that doesn't make it a program.
>> Why should one store such Xpath in (at least) two different files --
>> one for XSLT and one for XQuery?
How about one for Schematron and one for XSD ?
>> Why should one spend more time in doing this and create more
>> inconvenience to everybody?
I am not at all convinced that XPath expressions are so reusable that this is an inconvenience to anyone.
Although I have run into cases where things that make use of XPath are reusable ... within the context of a larger program.
>> Why should one have to maintain these at least two representations of
>> the same XPath code?
You dont unless you are using multiple languages. Stick with one language and you can reuse.
>> Why should one bear with syncronization problems and, at some time ,
>> having inevitably out of sync XSLT and XQuery representations, and
>> having to apply effort even to determine which is the newest one, or
>> if both have evolved independently and need a (non-trivial) merge?
Why not just pick one language and solve ALL those problems ?
>> Any XPath expression is a valid XQuery program.
>But XPath is intended to be used not only as a subset of XQuery.
True: But my point is if you want a langauage based on XQuery then why not just use XQuery ?
>> For example, implanting XPath code into XSLT requires some additional
>> effort and discipline.
Then just use XSLT and its methods of reuse.
Or perhaps evolve XSLT to be able to use XQuery modules and visa-versa.
But, IMHO, extending XPath even further to make it reusable and self contained ... is re-inventing XQuery. (or perhaps re-inventing XSLT).
That, IMHO, would make life *worse* for people as now we would have 3 self contained XML programming languages instead of 2.5
But to take your suggestion further.
I could have a "library" of reusable algebraic expressions that say worked in C, C++, Java , Pascal etc ...
like
SUM: a + b
Square: a*a
Increment: a + 1
But since these expressions have to be embedded in a calling language to be used we have the same problem.
Why not make a "library" of such expressions and expose them to all languages that share equivalent expression syntax?
All I would have to do is have a way of assigning a name to the expressions and a library format, and a way of invoking them by name.
Wouldn't this be a hugely valuable thing so when I write C programs and Java programs I dont have to maintain a seperate
definition of these common expressions ? We should extend the expression language so that it has named functions and
a common library format. That way I don't have to have the maintance nightmare of writing the same code in C and Java and C++ and C#.
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]