[xquery-talk] asterixdb

[Andy Bunce]

Hi,

Not tried it myself but, AsterixDB [1] may be of interest to XQuery users.

The heart of AQL[2] is the FLWOR (for-let-where-orderby-return)

expression. The roots of this expression were borrowed from the expression
of the same name in XQuery.

and

but XQuery was co-designed by a diverse band of experienced language

designers (SQL, functional programming,and XML experts)

and we wanted to avoid revisiting many of the same issues [3]

Regards
/Andy

[1] https://asterixdb.ics.uci.edu/
[2] https://asterixdb.ics.uci.edu/documentation/aql/manual.html
[3] http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf

[daniela florescu]

Andy,

The story is more complicated here.

The professor at Irvine Univ. in charge of the students team who designed AsterixDB, Mike Carey, is
today the Chief Architect of CouchDB, who ships the N1QL that I just sent yesterday.

Mike Carey knows exactly XQuery, given that he was in charge of my XQuery processor at BEA Systems after I left.

So it’s definitely not by lack of knowledge that he went BACKWARDS and N1QL is even more primitive then SQL 92
(just added some primitive forms of path expressions to it..)

It’s probably market pressure
.

IT HAS TO LOOK LIKE SQL, AND IT HAS TO USE THE THREE MAGIC KEYWORDS “select” “from” AND “where”.


Other then that, who cares that from a data processing perspective, we go backwards where we were in 1994 !???
(and nested select-from-where in the from clause are considered “disruptive” ..huh..)

Depressing.

Are users so ignorant and they prefer a vanilla syntax that they know over significant expressive power ?

I wonder.

Dana

Post by Andy Bunce
Hi,
Not tried it myself but, AsterixDB [1] may be of interest to XQuery users.

The heart of AQL[2] is the FLWOR (for-let-where-orderby-return) expression. The roots of this expression were borrowed from the expression of the same name in XQuery.

and

but XQuery was co-designed by a diverse band of experienced language designers (SQL, functional programming,and XML experts)
and we wanted to avoid revisiting many of the same issues [3]

Regards
/Andy
[1] https://asterixdb.ics.uci.edu/ <https://asterixdb.ics.uci.edu/>
[2] https://asterixdb.ics.uci.edu/documentation/aql/manual.html <https://asterixdb.ics.uci.edu/documentation/aql/manual.html>
[3] http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf <http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf>
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[Pavel Velikhov]

N1QL seems to have all the features to support a JSONiq front-end. Seems like a simple translation, except for the group-by clause.
I guess if people like 4-valued logic, breaking up constructors into group by and select clauses - let them have it :)

Post by daniela florescu
Andy,
The story is more complicated here.
The professor at Irvine Univ. in charge of the students team who designed AsterixDB, Mike Carey, is
today the Chief Architect of CouchDB, who ships the N1QL that I just sent yesterday.
Mike Carey knows exactly XQuery, given that he was in charge of my XQuery processor at BEA Systems after I left.
So it’s definitely not by lack of knowledge that he went BACKWARDS and N1QL is even more primitive then SQL 92
(just added some primitive forms of path expressions to it..)
It’s probably market pressure
.
IT HAS TO LOOK LIKE SQL, AND IT HAS TO USE THE THREE MAGIC KEYWORDS “select” “from” AND “where”.
Other then that, who cares that from a data processing perspective, we go backwards where we were in 1994 !???
(and nested select-from-where in the from clause are considered “disruptive” ..huh..)
Depressing.
Are users so ignorant and they prefer a vanilla syntax that they know over significant expressive power ?
I wonder.
Dana

Post by Andy Bunce
Hi,
Not tried it myself but, AsterixDB [1] may be of interest to XQuery users.

The heart of AQL[2] is the FLWOR (for-let-where-orderby-return) expression. The roots of this expression were borrowed from the expression of the same name in XQuery.

and

but XQuery was co-designed by a diverse band of experienced language designers (SQL, functional programming,and XML experts)
and we wanted to avoid revisiting many of the same issues [3]

Regards
/Andy
[1] https://asterixdb.ics.uci.edu/ <https://asterixdb.ics.uci.edu/>
[2] https://asterixdb.ics.uci.edu/documentation/aql/manual.html <https://asterixdb.ics.uci.edu/documentation/aql/manual.html>
[3] http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf <http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf>
_______________________________________________
http://x-query.com/mailman/listinfo/talk

_______________________________________________
http://x-query.com/mailman/listinfo/talk

С уважеМОеЌ,
Павел ВелОхПв
***@gmail.com

[daniela florescu]

No, Pavel, by no means, NO.

While N1Ql is finally something relatively well defined, and MUCH better then the alternatives,
in terms of expressive power, we go back to 1993.

N1QL is 99% a copy of OQL designed by Sophie Cluet in 1993 for object-oriented databases, which had
nested objects and arrays, and

After you got used to program in XQuery, going back to N1QL is going back to the cave age.

I personally won’t, and I would rather go did cow’s dung (time to review the classics

http://youtu.be/b2F-DItXtZs :-)

Here are a couple of things (random things that come to my mind in 3 seconds
..):

1. Compositionality. It’s 2015 , not 1977, for God’s sake.

2. Casts, explicit and implicit casts. Absolutely necessary for processing data of unknown structure.

3. If-then-elses. Absolutely necessary for processing data of unknown structure.

4. try-catch. Absolutely necessary for processing data of unknown structure.

5. Object and array constructors with dynamically computed content. It's 2015, not 1977 for God’s sake.

5. Functions and especially recursive functions. Absolutely necessary for processing data of unknown structure.

6. Declarative updates. No comment.

7. Full text. Again, it 2015, not 1977 for God’s sake.

=========

N1Ql is a cute little thing that brings us back in 1993
..:(


depressed.

Go back digging cow’s dung (or fashion in my case..) while people are still so ignorant in terms of data processing 



Wake me up when it’s done.

Dana

Post by Pavel Velikhov
N1QL seems to have all the features to support a JSONiq front-end. Seems like a simple translation, except for the group-by clause.
I guess if people like 4-valued logic, breaking up constructors into group by and select clauses - let them have it :)

Post by daniela florescu
Andy,
The story is more complicated here.
The professor at Irvine Univ. in charge of the students team who designed AsterixDB, Mike Carey, is
today the Chief Architect of CouchDB, who ships the N1QL that I just sent yesterday.
Mike Carey knows exactly XQuery, given that he was in charge of my XQuery processor at BEA Systems after I left.
So it’s definitely not by lack of knowledge that he went BACKWARDS and N1QL is even more primitive then SQL 92
(just added some primitive forms of path expressions to it..)
It’s probably market pressure
.
IT HAS TO LOOK LIKE SQL, AND IT HAS TO USE THE THREE MAGIC KEYWORDS “select” “from” AND “where”.
Other then that, who cares that from a data processing perspective, we go backwards where we were in 1994 !???
(and nested select-from-where in the from clause are considered “disruptive” ..huh..)
Depressing.
Are users so ignorant and they prefer a vanilla syntax that they know over significant expressive power ?
I wonder.
Dana

Post by Andy Bunce
Hi,
Not tried it myself but, AsterixDB [1] may be of interest to XQuery users.

The heart of AQL[2] is the FLWOR (for-let-where-orderby-return) expression. The roots of this expression were borrowed from the expression of the same name in XQuery.

and

but XQuery was co-designed by a diverse band of experienced language designers (SQL, functional programming,and XML experts)
and we wanted to avoid revisiting many of the same issues [3]

Regards
/Andy
[1] https://asterixdb.ics.uci.edu/ <https://asterixdb.ics.uci.edu/>
[2] https://asterixdb.ics.uci.edu/documentation/aql/manual.html <https://asterixdb.ics.uci.edu/documentation/aql/manual.html>
[3] http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf <http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf>
_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>

_______________________________________________
http://x-query.com/mailman/listinfo/talk

С уважеМОеЌ,
Павел ВелОхПв

[daniela florescu]

Post by daniela florescu
depressed.
Go back digging cow’s dung (or fashion in my case..) while people are still so ignorant in terms of data processing ……

I am GOING…. :-)))

Sorry for the misspelling ….

Dana



_______________________________________________
***@x-query.com
http://x-q

[daniela florescu]

And how can I forget to add to the list:

PATH EXPRESSIONS with good expressive power.

Again, we had them in XML since 1996.

It’s 2015, Pavel.

20 years later.


Best
Dana

Post by daniela florescu
No, Pavel, by no means, NO.
While N1Ql is finally something relatively well defined, and MUCH better then the alternatives,
in terms of expressive power, we go back to 1993.
N1QL is 99% a copy of OQL designed by Sophie Cluet in 1993 for object-oriented databases, which had
nested objects and arrays, and
After you got used to program in XQuery, going back to N1QL is going back to the cave age.
I personally won’t, and I would rather go did cow’s dung (time to review the classics http://youtu.be/b2F-DItXtZs http://youtu.be/b2F-DItXtZs :-)
1. Compositionality. It’s 2015 , not 1977, for God’s sake.
2. Casts, explicit and implicit casts. Absolutely necessary for processing data of unknown structure.
3. If-then-elses. Absolutely necessary for processing data of unknown structure.
4. try-catch. Absolutely necessary for processing data of unknown structure.
5. Object and array constructors with dynamically computed content. It's 2015, not 1977 for God’s sake.
5. Functions and especially recursive functions. Absolutely necessary for processing data of unknown structure.
6. Declarative updates. No comment.
7. Full text. Again, it 2015, not 1977 for God’s sake.
=========
N1Ql is a cute little thing that brings us back in 1993
..:(
depressed.
Go back digging cow’s dung (or fashion in my case..) while people are still so ignorant in terms of data processing 


Wake me up when it’s done.
Dana

Post by Pavel Velikhov
N1QL seems to have all the features to support a JSONiq front-end. Seems like a simple translation, except for the group-by clause.
I guess if people like 4-valued logic, breaking up constructors into group by and select clauses - let them have it :)

Post by daniela florescu
Andy,
The story is more complicated here.
The professor at Irvine Univ. in charge of the students team who designed AsterixDB, Mike Carey, is
today the Chief Architect of CouchDB, who ships the N1QL that I just sent yesterday.
Mike Carey knows exactly XQuery, given that he was in charge of my XQuery processor at BEA Systems after I left.
So it’s definitely not by lack of knowledge that he went BACKWARDS and N1QL is even more primitive then SQL 92
(just added some primitive forms of path expressions to it..)
It’s probably market pressure
.
IT HAS TO LOOK LIKE SQL, AND IT HAS TO USE THE THREE MAGIC KEYWORDS “select” “from” AND “where”.
Other then that, who cares that from a data processing perspective, we go backwards where we were in 1994 !???
(and nested select-from-where in the from clause are considered “disruptive” ..huh..)
Depressing.
Are users so ignorant and they prefer a vanilla syntax that they know over significant expressive power ?
I wonder.
Dana

Post by Andy Bunce
Hi,
Not tried it myself but, AsterixDB [1] may be of interest to XQuery users.

The heart of AQL[2] is the FLWOR (for-let-where-orderby-return) expression. The roots of this expression were borrowed from the expression of the same name in XQuery.

and

but XQuery was co-designed by a diverse band of experienced language designers (SQL, functional programming,and XML experts)
and we wanted to avoid revisiting many of the same issues [3]

Regards
/Andy
[1] https://asterixdb.ics.uci.edu/ <https://asterixdb.ics.uci.edu/>
[2] https://asterixdb.ics.uci.edu/documentation/aql/manual.html <https://asterixdb.ics.uci.edu/documentation/aql/manual.html>
[3] http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf <http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf>
_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>

_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>

С уважеМОеЌ,
Павел ВелОхПв

_______________________________________________
http://x-query.com/mailman/listinfo/talk

[Pavel Velikhov]

Yeah, I kind of missed that
 So there will be a N1QL v.2
 :)

Btw I like OQL much more than N1QL.

Post by daniela florescu
PATH EXPRESSIONS with good expressive power.
Again, we had them in XML since 1996.
It’s 2015, Pavel.
20 years later.
Best
Dana

Post by daniela florescu
No, Pavel, by no means, NO.
While N1Ql is finally something relatively well defined, and MUCH better then the alternatives,
in terms of expressive power, we go back to 1993.
N1QL is 99% a copy of OQL designed by Sophie Cluet in 1993 for object-oriented databases, which had
nested objects and arrays, and
After you got used to program in XQuery, going back to N1QL is going back to the cave age.
I personally won’t, and I would rather go did cow’s dung (time to review the classics http://youtu.be/b2F-DItXtZs http://youtu.be/b2F-DItXtZs :-)
1. Compositionality. It’s 2015 , not 1977, for God’s sake.
2. Casts, explicit and implicit casts. Absolutely necessary for processing data of unknown structure.
3. If-then-elses. Absolutely necessary for processing data of unknown structure.
4. try-catch. Absolutely necessary for processing data of unknown structure.
5. Object and array constructors with dynamically computed content. It's 2015, not 1977 for God’s sake.
5. Functions and especially recursive functions. Absolutely necessary for processing data of unknown structure.
6. Declarative updates. No comment.
7. Full text. Again, it 2015, not 1977 for God’s sake.
=========
N1Ql is a cute little thing that brings us back in 1993
..:(
depressed.
Go back digging cow’s dung (or fashion in my case..) while people are still so ignorant in terms of data processing 


Wake me up when it’s done.
Dana

Post by Pavel Velikhov
N1QL seems to have all the features to support a JSONiq front-end. Seems like a simple translation, except for the group-by clause.
I guess if people like 4-valued logic, breaking up constructors into group by and select clauses - let them have it :)

Post by daniela florescu
Andy,
The story is more complicated here.
The professor at Irvine Univ. in charge of the students team who designed AsterixDB, Mike Carey, is
today the Chief Architect of CouchDB, who ships the N1QL that I just sent yesterday.
Mike Carey knows exactly XQuery, given that he was in charge of my XQuery processor at BEA Systems after I left.
So it’s definitely not by lack of knowledge that he went BACKWARDS and N1QL is even more primitive then SQL 92
(just added some primitive forms of path expressions to it..)
It’s probably market pressure
.
IT HAS TO LOOK LIKE SQL, AND IT HAS TO USE THE THREE MAGIC KEYWORDS “select” “from” AND “where”.
Other then that, who cares that from a data processing perspective, we go backwards where we were in 1994 !???
(and nested select-from-where in the from clause are considered “disruptive” ..huh..)
Depressing.
Are users so ignorant and they prefer a vanilla syntax that they know over significant expressive power ?
I wonder.
Dana

Post by Andy Bunce
Hi,
Not tried it myself but, AsterixDB [1] may be of interest to XQuery users.

The heart of AQL[2] is the FLWOR (for-let-where-orderby-return) expression. The roots of this expression were borrowed from the expression of the same name in XQuery.

and

but XQuery was co-designed by a diverse band of experienced language designers (SQL, functional programming,and XML experts)
and we wanted to avoid revisiting many of the same issues [3]

Regards
/Andy
[1] https://asterixdb.ics.uci.edu/ <https://asterixdb.ics.uci.edu/>
[2] https://asterixdb.ics.uci.edu/documentation/aql/manual.html <https://asterixdb.ics.uci.edu/documentation/aql/manual.html>
[3] http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf <http://www.vldb.org/pvldb/vol7/p1905-alsubaiee.pdf>
_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>

_______________________________________________
http://x-query.com/mailman/listinfo/talk <http://x-query.com/mailman/listinfo/talk>

С уважеМОеЌ,
Павел ВелОхПв

_______________________________________________
http://x-query.com/mailman/listinfo/talk

С уважеМОеЌ,
Павел ВелОхПв
***@gmail.com

[daniela florescu]

Post by Pavel Velikhov
Yeah, I kind of missed that
 So there will be a N1QL v.2
 :)

Huh. I hope not. One cannot add “support for semi-structuredness” to a query language as an AFTER TOUGHT.

If you do that, you end up with new version of SQL-XML, which is a query language that only a tender mother can love.

Best
Dana

[Ghislain Fourny]

Hi,

I agree with Dana that XQuery has crucial features that address use cases
that emerged over the last decade. Both the SQL experience of the last 45
years and the XQuery experience from the last 15 years should be leveraged
by whichever language establishes itself on the document store processing
market. I think that ignoring the one or the other would imply a high
opportunity cost either way.

When describing languages, performance is often emphasized, for good
reasons. However, productivity and time-to-market are also very important.
I can see every single day how much time and money can be saved using
XQuery (or languages derived therefrom) and I would be quite reluctant to
switch to a language that doesn't have its features.

My 2 cents.

Kind regards,
Ghislain