From dflorescu at me.com  Sat May  2 23:02:18 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 02 May 2015 23:02:18 -0700
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
Message-ID: <94B9CB5F-B007-4939-B3C4-A15952C710C9@me.com>

Dear Gary Bloom,

you are the CEO of MarkLogic, and you are in cc of this message to those two esteemed XML-related mailing lists: xquery-talk and xml-dev.

To be honest, given the marketing screaming  that Marklogic did recently about your JSON support (geez, must have been expensive !!!), plus my messages
on those esteemed mailing lists, plus the amount of time and efforts that me and my Zorba team put into designing JSONiq (3 years)

http://www.jsoniq.org
??...

?...I was obviously slightly disappointed to see that nobody from MarkLogic had the intellectual honesty to give ME (and the others on the mailing lists)
 one of the  possible answers about MarkLogic?s JSON support:

(a) yes, we, MarkLogic, we inspired ourselves and adapt as much as we could from JSONiq, but we had no balls to admit it, and give proper scientific references to JSONiq

(b) no, we. MarkLogic, we designed everything from scratch without looking at JSONiq (but then, I would ask? Why !??.just curious...)

(c) yes, the language we, MarkLogic,  support is exactly the same language as JSONiq, but again, we lack the balls to admit it in front of the wholeXML/JSON  industry.

or any other such variation of such answer?.. pick your choice.

=============


I am asking you personally, Gary Bloom, CEO of MarkLogic, which one it is !?

Do you have any idea !?

No shame in stealing, Gary. After all, you come from Oracle, and Oracle was built on Ellison stealing IBM?s research, and Larry Ellison just bought an island?.
while IBM isn?t doing great?..

? so I wouldn?t blame you if your plan is the same  (small detail, I don?t have the kindness of character that Don Chamberlin from IBM had?just keep this in mind
for your future plans, though?..)

=============

Looking forward to your answer, Gary Bloom.

And in the meantime, yes, I admit, I was lazy. I could have gotten my own answer to that question about the technical differences between MarkLogic support of JSON
and JSONiq  (except that was looking forward to some intellectual honesty from MarkLogic, in vain, alas)

I will do my own own investigation about the technical differences between the two, and write a report.

Thanks for your (very telling, I am afraid?.) silence.

MarkLogic has no scientific strength, nor political and economical ?balls" (and sorry,  I am afraid that?s a technical term).

Best regards
Dana

P.S,. I?ll teach you a very useful Romanian saying : ?If you want to kill a cat, you can always say she has rabies?. 
Yep, tell anyone you want that I have rabies :-))))))






> On Apr 28, 2015, at 10:15 AM, daniela florescu <dflorescu at me.com> wrote:
> 
> Dear Kurt (Cagle) 
> 
> on linkedin to the same answer bellow you answered me:
> 
> "As I said, first glance says it's close, but I'm not completely up to date on the JSONIQ spec. I know when I talked to a key developer of mutual acquaintance, he indicated that he followed JSONIQ, but that was still while it was under development."
> 
> 
> Kurt, do you have now a better idea about the technical differences between the two JSOn query languages: JSONiq designed and supported by Zorba
> and the one supported by MarkLogic ? 
> 
> Or does someone else ?
> 
> What is the technical rationale for making the two languages different ? Any strong technical reasons ?
> 
> If there are no strong technical reasons, and the two are different just for the sake of being different, that's very sad. 
> 
> Relational databases survived for 30 years because those guys were brilliant business people and 
>  understood the power of a standard/common language and common APIs for all vendors.
> 
> It strengthens the (entire) community to the point that, even 30 years later, it is almost impossible to get SQL out of their hands....
> 
> It's very unfortunate that the NoSQL community, and especially MarkLogic who considers themselves the "leaders" in this market,
> don't get that simple fact....and they had to twist JSONiq here and there in order to avoid admitting they use the language designed by the
> Zorba community and avoid calling it JSONiq....
> 
> Such a lack of vision is sad.
> 
>  But I digress.
> 
> I am still curious if someone compiled a list of technical differences.
> 
> Thanks, best regards
> Dana
> 
> 
> 
>> On Apr 23, 2015, at 5:24 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> I heard that MarkLogic will be using JSONiq for processing JSON.
>> http://www.jsoniq.org <http://www.jsoniq.org/>
>> 
>> Sounds like wonderful news to me.
>> 
>> Hope it?s true.
>> 
>> Best
>> Dana
>> 
>> 
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150502/5a19ea34/attachment.html>

From mike at saxonica.com  Thu May  7 02:36:17 2015
From: mike at saxonica.com (Michael Kay)
Date: Thu, 7 May 2015 10:36:17 +0100
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
Message-ID: <609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>

I don?t know anything about the MarkLogic implementation, but some of the key differences between XQuery 3.1 and the JSONiq proposal are:

At the data model level:

* Maps can use any atomic value as the key, it does not have to be a string
* The members of an array are sequences, not necessarily items
* JSON?s null is represented as an empty sequence, not as a new atomic data type

At the syntax level:

* In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
* XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1

There are many differences of detail, for example XQ3.1 allows an array to be atomized, so that sum() over an array does "the right thing?.

Of course these differences were all very hotly debated over a long period of time, and I wouldn?t even attempt to summarize the arguments.

Michael Kay
Saxonica
mike at saxonica.com
+44 (0) 118 946 5893




> On 28 Apr 2015, at 18:15, daniela florescu <dflorescu at me.com> wrote:
> 
> Dear Kurt (Cagle) 
> 
> on linkedin to the same answer bellow you answered me:
> 
> "As I said, first glance says it's close, but I'm not completely up to date on the JSONIQ spec. I know when I talked to a key developer of mutual acquaintance, he indicated that he followed JSONIQ, but that was still while it was under development."
> 
> 
> Kurt, do you have now a better idea about the technical differences between the two JSOn query languages: JSONiq designed and supported by Zorba
> and the one supported by MarkLogic ? 
> 
> Or does someone else ?
> 
> What is the technical rationale for making the two languages different ? Any strong technical reasons ?
> 
> If there are no strong technical reasons, and the two are different just for the sake of being different, that's very sad. 
> 
> Relational databases survived for 30 years because those guys were brilliant business people and 
>  understood the power of a standard/common language and common APIs for all vendors.
> 
> It strengthens the (entire) community to the point that, even 30 years later, it is almost impossible to get SQL out of their hands....
> 
> It's very unfortunate that the NoSQL community, and especially MarkLogic who considers themselves the "leaders" in this market,
> don't get that simple fact....and they had to twist JSONiq here and there in order to avoid admitting they use the language designed by the
> Zorba community and avoid calling it JSONiq....
> 
> Such a lack of vision is sad.
> 
>  But I digress.
> 
> I am still curious if someone compiled a list of technical differences.
> 
> Thanks, best regards
> Dana
> 
> 
> 
>> On Apr 23, 2015, at 5:24 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> I heard that MarkLogic will be using JSONiq for processing JSON.
>> http://www.jsoniq.org <http://www.jsoniq.org/>
>> 
>> Sounds like wonderful news to me.
>> 
>> Hope it?s true.
>> 
>> Best
>> Dana
>> 
>> 
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150507/f68ff62e/attachment.html>

From jmdyck at ibiblio.org  Thu May  7 11:03:58 2015
From: jmdyck at ibiblio.org (Michael Dyck)
Date: Thu, 07 May 2015 14:03:58 -0400
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
Message-ID: <554BA90E.2060400@ibiblio.org>

On 15-05-07 01:06 PM, Schwartz, Christine wrote:
> I?m preparing an ALA preconference session for librarians titled ?Using
> XQuery as a Library Metadata Tool.? I?d like to provide the attendees
> with a list of XQuery resources so they can set up their own XQuery
> programming environment at their home institutions. Open source software
> is usually preferred by librarians, especially for grant projects.
>
> Any recommendations on what should be on this list?

The W3C's XQuery page <http://www.w3.org/XML/Query/> includes a list of
implementations (about 23 of which are marked "open source"), and suggests
some criteria by which to choose one.

-Michael




From adam.retter at googlemail.com  Thu May  7 11:14:12 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Thu, 7 May 2015 19:14:12 +0100
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
Message-ID: <CAPK0iciQVkxkK05ZD3WjdkoYMPqVTakkLSsq2OkwZCWbj+dHkw@mail.gmail.com>

Hi Christine,

Here are some suggestions for you -

XML Native Databases -> eXist, BaseX, and Sedna (still maintained?)

XQuery standalone processors -> Saxon, XQilla (still maintained?) and
Apache VXQuery

XSLT standalone processors -> Saxon.

XML IDE -> Oxygen (not Open Source, but relatively cheap) and eXide
(eXist only).

Also if you have to do any work with RDF and Sparql, then I can
recommend Apache Jena.

Cheers Adam.

On 7 May 2015 at 18:06, Schwartz, Christine
<christine.schwartz at ptsem.edu> wrote:
> I?m preparing an ALA preconference session for librarians titled ?Using
> XQuery as a Library Metadata Tool.? I?d like to provide the attendees with a
> list of XQuery resources so they can set up their own XQuery programming
> environment at their home institutions. Open source software is usually
> preferred by librarians, especially for grant projects.
>
>
>
> I feel a little handicapped in this area as I?ve been using MarkLogic for
> over seven years and have not had to work with open source XQuery tools.
>
>
>
> Any recommendations on what should be on this list?
>
>
>
> Thanks,
>
>
>
> Chris
>
>
>
> Christine Schwartz
>
> Metadata Librarian and XML Database Administrator
>
> Princeton Theological Seminary Library
>
> 25 Library Place
>
> Princeton, NJ 08540
>
> christine.schwartz at ptsem.edu
>
>
>
>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk


From liam at w3.org  Thu May  7 11:17:45 2015
From: liam at w3.org (Liam R. E. Quin)
Date: Thu, 07 May 2015 14:17:45 -0400
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
Message-ID: <1431022665.2899.41.camel@w3.org>

On Thu, 2015-05-07 at 17:06 +0000, Schwartz, Christine wrote:
> I'm preparing an ALA preconference session for librarians titled 
> "Using XQuery as a Library Metadata Tool." I'd like to provide the 
> attendees with a list of XQuery resources so they can set up their 
> own XQuery programming environment at their home institutions. Open 
> source software is usually preferred by librarians, especially for 
> grant projects.
> 
> I feel a little handicapped in this area as I've been using 
> MarkLogic for over seven years and have not had to work with open 
> source XQuery tools.

I on the other hand have not used MarkLogic.

BaseX and eXist seem to be the most widely used. There is also Zorba, 
although I found it difficult to set up, and Sedna, which seems not to 
be actively maintained.

Usually I send people to BaseX in the first instance, as the easiest 
to get started (it's written in Java and has a GUI, and can be used 
also from PHP, Perl, etc.; most people I've spoken with seem to have 
their first query running within a few minutes of downloading the 
software).

For a mixed relation + XML model, Virtuoso supports XQuery, although I 
have not tried it.

What I believe is most important is to keep any software-specific 
extensions isolated from the main queries, so you can easily switch.

I should really update www.w3.org/XML/Query/ to reflect XQuery 3.0 
reality.

Liam

> Any recommendations on what should be on this list?
> 
> Thanks,
> 
> Chris
> 
> Christine Schwartz
> Metadata Librarian and XML Database Administrator
> Princeton Theological Seminary Library
> 25 Library Place
> Princeton, NJ 08540
> christine.schwartz at ptsem.edu<mailto:christine.schwartz at ptsem.edu>
> 
> 
> _______________________________________________ talk at x-query.com 
> http://x-query.com/mailman/listinfo/talk

From mike at saxonica.com  Thu May  7 11:19:39 2015
From: mike at saxonica.com (Michael Kay)
Date: Thu, 7 May 2015 19:19:39 +0100
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
Message-ID: <BC4F6718-AB07-417D-A639-E51AC2DFA1B0@saxonica.com>

Are you looking for database implementations of XQuery, or ?filestore? implementations?

Michael Kay
Saxonica
mike at saxonica.com
+44 (0) 118 946 5893




> On 7 May 2015, at 18:06, Schwartz, Christine <christine.schwartz at ptsem.edu> wrote:
> 
> I?m preparing an ALA preconference session for librarians titled ?Using XQuery as a Library Metadata Tool.? I?d like to provide the attendees with a list of XQuery resources so they can set up their own XQuery programming environment at their home institutions. Open source software is usually preferred by librarians, especially for grant projects.
>  
> I feel a little handicapped in this area as I?ve been using MarkLogic for over seven years and have not had to work with open source XQuery tools.
>  
> Any recommendations on what should be on this list?
>  
> Thanks,
>  
> Chris
>  
> Christine Schwartz
> Metadata Librarian and XML Database Administrator
> Princeton Theological Seminary Library
> 25 Library Place
> Princeton, NJ 08540
> christine.schwartz at ptsem.edu <mailto:christine.schwartz at ptsem.edu>
>  
>  
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150507/b46c6227/attachment.html>

From adam.retter at googlemail.com  Thu May  7 11:33:49 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Thu, 7 May 2015 19:33:49 +0100
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <554BA90E.2060400@ibiblio.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<554BA90E.2060400@ibiblio.org>
Message-ID: <CAPK0icjBED5X8t3sNaw6rZjoNXJyC0Qfk=_h2ieeQ_kuncX=RA@mail.gmail.com>

I recently trawled the list here -
http://www.w3.org/XML/Query/#implementations for a survey of
implementations that I am producing. Unfortunately I found many of the
links to be out of date. I guess some of these companies/projects have
moved on or folded. Certainly todays list of implementations is much
shorter. I wonder if we should not update that list even if it has an
"archive" part?

On 7 May 2015 at 19:03, Michael Dyck <jmdyck at ibiblio.org> wrote:
> On 15-05-07 01:06 PM, Schwartz, Christine wrote:
>>
>> I?m preparing an ALA preconference session for librarians titled ?Using
>> XQuery as a Library Metadata Tool.? I?d like to provide the attendees
>> with a list of XQuery resources so they can set up their own XQuery
>> programming environment at their home institutions. Open source software
>> is usually preferred by librarians, especially for grant projects.
>>
>> Any recommendations on what should be on this list?
>
>
> The W3C's XQuery page <http://www.w3.org/XML/Query/> includes a list of
> implementations (about 23 of which are marked "open source"), and suggests
> some criteria by which to choose one.
>
> -Michael
>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk


From christine.schwartz at ptsem.edu  Thu May  7 12:14:39 2015
From: christine.schwartz at ptsem.edu (Schwartz, Christine)
Date: Thu, 7 May 2015 19:14:39 +0000
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <BC4F6718-AB07-417D-A639-E51AC2DFA1B0@saxonica.com>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<BC4F6718-AB07-417D-A639-E51AC2DFA1B0@saxonica.com>
Message-ID: <9A3223ADEBFC75488A09810F4478FE4AFC6A6559@Exchange01.pts-eden.org>

Thank you to all who responded to my question. I?m anticipating that most people attending this workshop will not have a programming background. So, simplicity is important. I?d like participants to leave feeling empowered and not overwhelmed (at least that?s my goal).

In answer to Michael?s question, while I think a database implementation would be preferable (for working with XQuery), there are some librarians who may not have the IT support for a database implementation and I?d like to guide them to ?filestore? implementations also.

Thanks,

Chris

From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf Of Michael Kay
Sent: Thursday, May 07, 2015 2:20 PM
To: Schwartz, Christine
Cc: talk at x-query.com
Subject: Re: [xquery-talk] Open source XQuery processors

Are you looking for database implementations of XQuery, or ?filestore? implementations?

Michael Kay
Saxonica
mike at saxonica.com<mailto:mike at saxonica.com>
+44 (0) 118 946 5893



On 7 May 2015, at 18:06, Schwartz, Christine <christine.schwartz at ptsem.edu<mailto:christine.schwartz at ptsem.edu>> wrote:

I?m preparing an ALA preconference session for librarians titled ?Using XQuery as a Library Metadata Tool.? I?d like to provide the attendees with a list of XQuery resources so they can set up their own XQuery programming environment at their home institutions. Open source software is usually preferred by librarians, especially for grant projects.

I feel a little handicapped in this area as I?ve been using MarkLogic for over seven years and have not had to work with open source XQuery tools.

Any recommendations on what should be on this list?

Thanks,

Chris

Christine Schwartz
Metadata Librarian and XML Database Administrator
Princeton Theological Seminary Library
25 Library Place
Princeton, NJ 08540
christine.schwartz at ptsem.edu<mailto:christine.schwartz at ptsem.edu>


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150507/cde73eb6/attachment.html>

From per at bothner.com  Thu May  7 13:09:32 2015
From: per at bothner.com (Per Bothner)
Date: Thu, 07 May 2015 13:09:32 -0700
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <1431022665.2899.41.camel@w3.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<1431022665.2899.41.camel@w3.org>
Message-ID: <554BC67C.60007@bothner.com>



On 05/07/2015 11:17 AM, Liam R. E. Quin wrote:
> I should really update www.w3.org/XML/Query/ to reflect XQuery 3.0
> reality.

Qexo (Kawa-XQuery) is still maintained but not actively developed. I.e. I still
make occasional fixes, and I run the testsuite frequently to make sure
I don't break it when I make unrelated changes to the Kawa framework.
Qexo only supports XQuery 1.0, and there are no current plans to add
the newer extensions.

Qexo is file-oriented (not database-oriented) and it's easy to set up and run.
It does have a REPL.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/

From liam at w3.org  Thu May  7 13:36:46 2015
From: liam at w3.org (Liam R. E. Quin)
Date: Thu, 07 May 2015 16:36:46 -0400
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <1431022665.2899.41.camel@w3.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<1431022665.2899.41.camel@w3.org>
Message-ID: <1431031006.2899.49.camel@w3.org>

On Thu, 2015-05-07 at 14:17 -0400, Liam R. E. Quin wrote:
[...]
> BaseX and eXist seem to be the most widely used. There is also > 
Zorba, although I found it difficult to set up, and Sedna, which > 
seems not to be actively maintained.

Somehow I forgot to mention Saxon (a filestore-based implementation), 
sorry about that.

> I should really update   www.w3.org/XML/Query/toreflect XQuery 3.0 
reality.

Or should I move it to a wiki?


Liam


From wcandillon at gmail.com  Thu May  7 15:26:32 2015
From: wcandillon at gmail.com (William Candillon)
Date: Thu, 7 May 2015 15:26:32 -0700
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <1431022665.2899.41.camel@w3.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<1431022665.2899.41.camel@w3.org>
Message-ID: <CAM7ytN-GphJEYV1CpbM1mctzb_NDFW5vfcnxQK9K5Uinq6NdAA@mail.gmail.com>

On Thu, May 7, 2015 at 11:17 AM, Liam R. E. Quin <liam at w3.org> wrote:
> On Thu, 2015-05-07 at 17:06 +0000, Schwartz, Christine wrote:
>> I'm preparing an ALA preconference session for librarians titled
>> "Using XQuery as a Library Metadata Tool." I'd like to provide the
>> attendees with a list of XQuery resources so they can set up their
>> own XQuery programming environment at their home institutions. Open
>> source software is usually preferred by librarians, especially for
>> grant projects.
>>
>> I feel a little handicapped in this area as I've been using
>> MarkLogic for over seven years and have not had to work with open
>> source XQuery tools.
>
> I on the other hand have not used MarkLogic.
>
> BaseX and eXist seem to be the most widely used. There is also Zorba,
> although I found it difficult to set up, and Sedna, which seems not to
> be actively maintained.
That is absolutely true. We are currently tackling this problem.
We are providing a simple docker container for Zorba at the moment:
https://registry.hub.docker.com/u/wcandillon/zorba/
We are looking to provide in the future a Zorba service via docker
that can be consumed easily from php, java and son.

In the list of open source IDEs, I would like to add Atom
(https://atom.io/packages/language-jsoniq) and Cloud9.

>
> Usually I send people to BaseX in the first instance, as the easiest
> to get started (it's written in Java and has a GUI, and can be used
> also from PHP, Perl, etc.; most people I've spoken with seem to have
> their first query running within a few minutes of downloading the
> software).
>
> For a mixed relation + XML model, Virtuoso supports XQuery, although I
> have not tried it.
>
> What I believe is most important is to keep any software-specific
> extensions isolated from the main queries, so you can easily switch.
>
> I should really update www.w3.org/XML/Query/ to reflect XQuery 3.0
> reality.
>
> Liam
>
>> Any recommendations on what should be on this list?
>>
>> Thanks,
>>
>> Chris
>>
>> Christine Schwartz
>> Metadata Librarian and XML Database Administrator
>> Princeton Theological Seminary Library
>> 25 Library Place
>> Princeton, NJ 08540
>> christine.schwartz at ptsem.edu<mailto:christine.schwartz at ptsem.edu>
>>
>>
>> _______________________________________________ talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

From rpbourret at rpbourret.com  Thu May  7 16:01:26 2015
From: rpbourret at rpbourret.com (Ronald Bourret)
Date: Thu, 07 May 2015 16:01:26 -0700
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <9A3223ADEBFC75488A09810F4478FE4AFC6A6559@Exchange01.pts-eden.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>	<BC4F6718-AB07-417D-A639-E51AC2DFA1B0@saxonica.com>
	<9A3223ADEBFC75488A09810F4478FE4AFC6A6559@Exchange01.pts-eden.org>
Message-ID: <554BEEC6.6020902@rpbourret.com>

One thing to consider in this regard is how much data you have. It's 
easy to imagine libraries having a lot of data and this could cause 
performance problems.

As a general rule, file-based XQuery implementations parse XML documents 
at run-time, rather than at file-load time, as is the case with database 
XQuery implementations. This can be quite slow for large documents. In 
addition, file-based XQuery implementations will have at best limited 
indexes, which also adversely affects performance.

-- Ron

On 5/7/2015 12:14 PM, Schwartz, Christine wrote:
> In answer to Michael?s question, while I think a database implementation
> would be preferable (for working with XQuery), there are some librarians
> who may not have the IT support for a database implementation and I?d
> like to guide them to ?filestore? implementations also.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


From liam at w3.org  Thu May  7 17:52:17 2015
From: liam at w3.org (Liam R. E. Quin)
Date: Thu, 07 May 2015 20:52:17 -0400
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <554BBE0B.9060100@benibela.de>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<554BBE0B.9060100@benibela.de>
Message-ID: <1431046337.2899.54.camel@w3.org>

On Thu, 2015-05-07 at 21:33 +0200, Benito van der Zander wrote:
> Hi,
> 
> I wrote one: http://videlibri.sourceforge.net/xidel.html

Benito, I'm glad you posted - I added Xidel to www.w3.org/XML/Query 
and should have added it last year.

Liam

> 
> Online version: 
> http://videlibri.sourceforge.net/cgi-bin/xidelcgi?xquery=(1 to 50)
> 
> It is interpreting a language half way between XQuery 1 and XQuery 3 
> at the moment.
> As well as JSONiq.
> 
> Sometimes its error checking is too weak and it evaluates stuff that 
> is not valid XQuery
> 
> Originally it was a library app, which lets you view your library 
> account and do stuff like automatically
> renewing everything, before it is due.
> To allow everyone to add their own catalog without much effort, I 
> implemented a language similar
> to XPath with some extensions. But then everyone said that is far 
> too complicated and they won't do it.
> So I had mostly stopped working on that aspect and changed it to 
> become a standard-compatible
> XQuery engine instead, without anything related to libraries.
> 
> Best,
> Benito
> 
> 
> 
> On 05/07/2015 07:06 PM, Schwartz, Christine wrote:
> > 
> > I?m preparing an ALA preconference session for librarians titled 
> > ?Using XQuery as a Library Metadata Tool.? I?d like to provide the 
> > attendees with a list of XQuery resources so they can set up their 
> > own XQuery programming environment at their home institutions. 
> > Open source software is usually preferred by librarians, 
> > especially for grant projects.
> > 
> > I feel a little handicapped in this area as I?ve been using 
> > MarkLogic for over seven years and have not had to work with open 
> > source XQuery tools.
> > 
> > Any recommendations on what should be on this list?
> > 
> > Thanks,
> > 
> > Chris
> > 
> > Christine Schwartz
> > 
> > Metadata Librarian and XML Database Administrator
> > 
> > Princeton Theological Seminary Library
> > 
> > 25 Library Place
> > 
> > Princeton, NJ 08540
> > 
> >  christine.schwartz at ptsem.edu<mailto:christine.schwartz at ptsem.edu>
> > 
> > 
> > 
> > _______________________________________________ talk at x-query.com 
> > http://x-query.com/mailman/listinfo/talk
> 
> _______________________________________________ talk at x-query.com 
> http://x-query.com/mailman/listinfo/talk

From benito at benibela.de  Fri May  8 00:21:30 2015
From: benito at benibela.de (Benito van der Zander)
Date: Fri, 08 May 2015 09:21:30 +0200
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <1431046337.2899.54.camel@w3.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>	<554BBE0B.9060100@benibela.de>
	<1431046337.2899.54.camel@w3.org>
Message-ID: <554C63FA.3050804@benibela.de>

Hi Liam,

oh, you did add it last year.

Now it is listed there three times!

Once as VideLibri from the time it was XPath 2 only.  (still has a 
"accept only XPath 2" mode)

Bye,
Benito



On 05/08/2015 02:52 AM, Liam R. E. Quin wrote:
> On Thu, 2015-05-07 at 21:33 +0200, Benito van der Zander wrote:
>> Hi,
>>
>> I wrote one: http://videlibri.sourceforge.net/xidel.html
> Benito, I'm glad you posted - I added Xidel to www.w3.org/XML/Query
> and should have added it last year.
>
> Liam
>
>> Online version:
>> http://videlibri.sourceforge.net/cgi-bin/xidelcgi?xquery=(1 to 50)
>>
>> It is interpreting a language half way between XQuery 1 and XQuery 3
>> at the moment.
>> As well as JSONiq.
>>
>> Sometimes its error checking is too weak and it evaluates stuff that
>> is not valid XQuery
>>
>> Originally it was a library app, which lets you view your library
>> account and do stuff like automatically
>> renewing everything, before it is due.
>> To allow everyone to add their own catalog without much effort, I
>> implemented a language similar
>> to XPath with some extensions. But then everyone said that is far
>> too complicated and they won't do it.
>> So I had mostly stopped working on that aspect and changed it to
>> become a standard-compatible
>> XQuery engine instead, without anything related to libraries.
>>
>> Best,
>> Benito
>>
>>
>>
>> On 05/07/2015 07:06 PM, Schwartz, Christine wrote:
>>> I?m preparing an ALA preconference session for librarians titled
>>> ?Using XQuery as a Library Metadata Tool.? I?d like to provide the
>>> attendees with a list of XQuery resources so they can set up their
>>> own XQuery programming environment at their home institutions.
>>> Open source software is usually preferred by librarians,
>>> especially for grant projects.
>>>
>>> I feel a little handicapped in this area as I?ve been using
>>> MarkLogic for over seven years and have not had to work with open
>>> source XQuery tools.
>>>
>>> Any recommendations on what should be on this list?
>>>
>>> Thanks,
>>>
>>> Chris
>>>
>>> Christine Schwartz
>>>
>>> Metadata Librarian and XML Database Administrator
>>>
>>> Princeton Theological Seminary Library
>>>
>>> 25 Library Place
>>>
>>> Princeton, NJ 08540
>>>
>>>   christine.schwartz at ptsem.edu<mailto:christine.schwartz at ptsem.edu>
>>>
>>>
>>>
>>> _______________________________________________ talk at x-query.com
>>> http://x-query.com/mailman/listinfo/talk
>> _______________________________________________ talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From g at 28.io  Fri May  8 02:06:17 2015
From: g at 28.io (Ghislain Fourny)
Date: Fri, 8 May 2015 11:06:17 +0200
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <1431022665.2899.41.camel@w3.org>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<1431022665.2899.41.camel@w3.org>
Message-ID: <CAPa8FbScA3Y=0fzyUougF_3iWmTCkFJBziqjc1L6C9fS9yy6iQ@mail.gmail.com>

Hi Liam,

> There is also Zorba, although I found it difficult to set up

This has changed :-) There is now a Docker container for Zorba, so no
more specific setup is required besides installing Docker and the
Zorba container. All the dependencies are encapsulated and installed
in the container.

https://registry.hub.docker.com/u/wcandillon/zorba/

Kind regards,
Ghislain

From dflorescu at me.com  Fri May  8 02:29:28 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 08 May 2015 02:29:28 -0700
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
Message-ID: <7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>

Michael,

Nothing seems fundamentally ?right? or ?wrong? one way or the other in what you say.
(syntax in XQuery 3.1 seems uglier then JSONiq to me though?..)

So, to me,  the decisions of the W3C working group seems random, and rather based on a two years old
kind of a  tantrum ?I WANT TO BE DIFFERETENT JUST BECAUSE?..I WANT IT."


??...rather then justified by any technical reasons.


This is why this community will die (unless they change, and this unfortunately involves changing the leaders).


Because everybody thinks about their small itsy-bitsy ego, and their itsy-bisty market, instead of the bigger picture.


D.


> On May 7, 2015, at 2:36 AM, Michael Kay <mike at saxonica.com> wrote:
> 
> I don?t know anything about the MarkLogic implementation, but some of the key differences between XQuery 3.1 and the JSONiq proposal are:
> 
> At the data model level:
> 
> * Maps can use any atomic value as the key, it does not have to be a string
> * The members of an array are sequences, not necessarily items
> * JSON?s null is represented as an empty sequence, not as a new atomic data type
> 
> At the syntax level:
> 
> * In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
> * XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1
> 
> There are many differences of detail, for example XQ3.1 allows an array to be atomized, so that sum() over an array does "the right thing?.
> 
> Of course these differences were all very hotly debated over a long period of time, and I wouldn?t even attempt to summarize the arguments.
> 
> Michael Kay
> Saxonica
> mike at saxonica.com <mailto:mike at saxonica.com>
> +44 (0) 118 946 5893
> 
> 
> 
> 
>> On 28 Apr 2015, at 18:15, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> Dear Kurt (Cagle) 
>> 
>> on linkedin to the same answer bellow you answered me:
>> 
>> "As I said, first glance says it's close, but I'm not completely up to date on the JSONIQ spec. I know when I talked to a key developer of mutual acquaintance, he indicated that he followed JSONIQ, but that was still while it was under development."
>> 
>> 
>> Kurt, do you have now a better idea about the technical differences between the two JSOn query languages: JSONiq designed and supported by Zorba
>> and the one supported by MarkLogic ? 
>> 
>> Or does someone else ?
>> 
>> What is the technical rationale for making the two languages different ? Any strong technical reasons ?
>> 
>> If there are no strong technical reasons, and the two are different just for the sake of being different, that's very sad. 
>> 
>> Relational databases survived for 30 years because those guys were brilliant business people and 
>>  understood the power of a standard/common language and common APIs for all vendors.
>> 
>> It strengthens the (entire) community to the point that, even 30 years later, it is almost impossible to get SQL out of their hands....
>> 
>> It's very unfortunate that the NoSQL community, and especially MarkLogic who considers themselves the "leaders" in this market,
>> don't get that simple fact....and they had to twist JSONiq here and there in order to avoid admitting they use the language designed by the
>> Zorba community and avoid calling it JSONiq....
>> 
>> Such a lack of vision is sad.
>> 
>>  But I digress.
>> 
>> I am still curious if someone compiled a list of technical differences.
>> 
>> Thanks, best regards
>> Dana
>> 
>> 
>> 
>>> On Apr 23, 2015, at 5:24 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>>> 
>>> I heard that MarkLogic will be using JSONiq for processing JSON.
>>> http://www.jsoniq.org <http://www.jsoniq.org/>
>>> 
>>> Sounds like wonderful news to me.
>>> 
>>> Hope it?s true.
>>> 
>>> Best
>>> Dana
>>> 
>>> 
>> 
>> _______________________________________________
>> talk at x-query.com <mailto:talk at x-query.com>
>> http://x-query.com/mailman/listinfo/talk
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150508/106e274a/attachment.html>

From dflorescu at me.com  Fri May  8 02:43:42 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 08 May 2015 02:43:42 -0700
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <CAPa8FbScA3Y=0fzyUougF_3iWmTCkFJBziqjc1L6C9fS9yy6iQ@mail.gmail.com>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<1431022665.2899.41.camel@w3.org>
	<CAPa8FbScA3Y=0fzyUougF_3iWmTCkFJBziqjc1L6C9fS9yy6iQ@mail.gmail.com>
Message-ID: <9AAA396C-325C-4CD7-A217-A04376A7F701@me.com>

Ghislain,

no matter how much gift wrapping paper and Christmas bows you try to put on it, the Zorba code 
is dead, because of the Zorba team doesn?t exist anymore, and no-one maintains almost a million lines of
C++ code.


So please don?t lead our users into that. 


It?s not fair to them.


If others teams want to mislead their users, let them do, but, but as an ex-architect of Zorba I feel the need to be honest with our users.

Zorba is dead (or frozen in time for the moment).


Best regards
Dana






> On May 8, 2015, at 2:06 AM, Ghislain Fourny <g at 28.io> wrote:
> 
> Hi Liam,
> 
>> There is also Zorba, although I found it difficult to set up
> 
> This has changed :-) There is now a Docker container for Zorba, so no
> more specific setup is required besides installing Docker and the
> Zorba container. All the dependencies are encapsulated and installed
> in the container.
> 
> https://registry.hub.docker.com/u/wcandillon/zorba/
> 
> Kind regards,
> Ghislain
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From mike at saxonica.com  Fri May  8 04:09:05 2015
From: mike at saxonica.com (Michael Kay)
Date: Fri, 8 May 2015 12:09:05 +0100
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
Message-ID: <8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>

> 
> So, to me,  the decisions of the W3C working group seems random, and rather based on a two years old
> kind of a  tantrum ?I WANT TO BE DIFFERETENT JUST BECAUSE?..I WANT IT."
> 
> 
> ??...rather then justified by any technical reasons.
> 

No, all the arguments were all technical. For example:

* generalizing maps to allow any atomic type as the key, rather than only a string, was because of specific use cases that required this (remember that the first proposal to add maps to XDM came from XSLT streaming work, not from JSONiq)

* the decision to use ?map{?}? rather than ?{?}? was to some extent subjective, but was motivated by technical arguments such as the ability to produce good error messages, retaining options for future extensions to the grammar, etc. Expressions beginning with ?{? are particularly problematic because ?{? is used to delimit embedded expressions in element content, and ?{{? is used to escape ?{? as an ordinary character; they are also very obscure when used as the body of a function (declare function f {{1:2}}). Before making this decision, we looked at how many other popular languages solve this problem.

* the decision to allow any sequence to act as a member of an array enabled things like the fn:apply() function, whose second argument is an array of arbitrary sequences; it also enabled JSON null to be represented by an empty sequence, which avoided the need for pervasive changes to the language to define how every function and operator should handle a JSON null. Reducing the number of concepts by one is a definite plus.

Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well. If there?s one aspect I?m still a little unhappy about, it?s the fact that an array behaves like a single item, so for example

let $A := [1,2,3]
return $A[1]

returns [1,2,3]

But that?s there because we tried very hard to find a way to avoid this surprise, and failed: the sequence=item model in XDM is just too deeply embedded.

Michael Kay
Saxonica



From adam.retter at googlemail.com  Fri May  8 04:21:58 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Fri, 8 May 2015 12:21:58 +0100
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
Message-ID: <CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>

> No, all the arguments were all technical
>
> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well.

Absolutely! Whilst I am more of an occasional frequenter and
contributor to the XQuery WG, having seen the level of collaborative
work and perseverance that that has gone into adding Maps and Arrays
to XQuery, I can say that I am impressed.

>From my perspective, it was a difficult process, but everyone worked
hard together and the technical arguments were always foremost. Whilst
working under the constraints of backwards compatibility and creating
a cohesive data model and language, I think the result speaks for
itself. Certainly many of eXist's users are very happy with the new
Maps and Arrays work in XQuery 3.1 and we frequently receive positive
feedback on this.



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

From g at 28.io  Fri May  8 05:46:03 2015
From: g at 28.io (Ghislain Fourny)
Date: Fri, 8 May 2015 14:46:03 +0200
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
Message-ID: <CAPa8FbRLGwy3sNPEF7dA_rRa8=TOx2hJUZ6Gdogm8obP-88u_g@mail.gmail.com>

Hi,

My understanding of the reason why XQuery 3.1 and JSONiq diverge is
also use-case based. If you are interested in some more background, I
believe there were two drivers all along:

1. Support for NoSQL document store querying.
2. Support for map and array structures in memory.

Both use cases are important, even if their importance varies from
project to project or from company to company.

JSONiq was designed 100% for NoSQL document store querying : it is (on
purpose) optimized for supporting use case 1 and only use case 1.

XQuery 3.1 also covers use case 2. Supporting both use cases and
making compromises between the two was not trivial, which is why there
was a lot of work put into the discussions and the design in the
working group.

I share Adam's feeling 100%. Everybody took the time to patiently
listen to one another, which is one of the aspects of the working
group I valued the most. I enjoyed each meeting we had and learned a
lot from the discussions -- paradoxically, I also had the feeling of
knowing JSONiq better after having them.

To me, one of the main concrete technical differences (if I correctly
remember) is that JSONiq manipulates trees/documents (both with XML
and JSON), so that when you put data into an object, it is copied over
(even if most of the time the optimizer can spare the actual copying).
This eliminates many serialization issues when data gets roundtripped
around. XQuery 3.1 is more data-structure oriented as use case 2
requires retaining the original identity of map and array values,
which theoretically allows graphs. This difference is important and
noticeable when updates and scripting kick in.

Of course, for each set of use cases, standards and interoperability
are always desirable, so I can understand Dana's discomfort. I also
think, though, that it is natural for different languages to emerge if
the use cases differ and, in the broader context of IT, think that it
is wise to pragmatically select technologies based on what one wants
to achieve.

On the bright side also: the data models behind the languages are
similar, and both languages can run on the same virtual machine. Zorba
already supports XQuery 3.0 and JSONiq side by side.

I hope it makes sense.

Kind regards,
Ghislain


On Fri, May 8, 2015 at 1:21 PM, Adam Retter <adam.retter at googlemail.com> wrote:
>> No, all the arguments were all technical
>>
>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well.
>
> Absolutely! Whilst I am more of an occasional frequenter and
> contributor to the XQuery WG, having seen the level of collaborative
> work and perseverance that that has gone into adding Maps and Arrays
> to XQuery, I can say that I am impressed.
>
> From my perspective, it was a difficult process, but everyone worked
> hard together and the technical arguments were always foremost. Whilst
> working under the constraints of backwards compatibility and creating
> a cohesive data model and language, I think the result speaks for
> itself. Certainly many of eXist's users are very happy with the new
> Maps and Arrays work in XQuery 3.1 and we frequently receive positive
> feedback on this.
>
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

From liam at w3.org  Fri May  8 12:01:16 2015
From: liam at w3.org (Liam R. E. Quin)
Date: Fri, 08 May 2015 15:01:16 -0400
Subject: [xquery-talk] Open source XQuery processors
In-Reply-To: <554C63FA.3050804@benibela.de>
References: <9A3223ADEBFC75488A09810F4478FE4AFC6A5439@Exchange01.pts-eden.org>
	<554BBE0B.9060100@benibela.de> <1431046337.2899.54.camel@w3.org>
	<554C63FA.3050804@benibela.de>
Message-ID: <1431111676.2899.72.camel@w3.org>

On Fri, 2015-05-08 at 09:21 +0200, Benito van der Zander wrote:
> Hi Liam,
> 
> oh, you did add it last year.
> 
> Now it is listed there three times!

OK, now you are 
> 
> Once as VideLibri from the time it was XPath 2 only.  (still has a 
> "accept only XPath 2" mode)

I left the entry for VideLibri but mentioned further work continues 
under the name Xidel.

Thanks

> Bye,
> Benito
> 
> 
> 
> On 05/08/2015 02:52 AM, Liam R. E. Quin wrote:
> > On Thu, 2015-05-07 at 21:33 +0200, Benito van der Zander wrote:
> > > Hi,
> > > 
> > > I wrote one: http://videlibri.sourceforge.net/xidel.html
> > Benito, I'm glad you posted - I added Xidel to  www.w3.org/XML/Query
> > and should have added it last year.
> > 
> > Liam
> > 
> > > Online version: 
> > > http://videlibri.sourceforge.net/cgi-bin/xidelcgi?xquery=(1 to 
> > > 50)
> > > 
> > > It is interpreting a language half way between XQuery 1 and 
> > > XQuery 3 at the moment.
> > > As well as JSONiq.
> > > 
> > > Sometimes its error checking is too weak and it evaluates stuff 
> > > that is not valid XQuery
> > > 
> > > Originally it was a library app, which lets you view your 
> > > library account and do stuff like automatically
> > > renewing everything, before it is due.
> > > To allow everyone to add their own catalog without much effort, I
> > > implemented a language similar
> > > to XPath with some extensions. But then everyone said that is 
> > > far too complicated and they won't do it.
> > > So I had mostly stopped working on that aspect and changed it to 
> > > become a standard-compatible
> > > XQuery engine instead, without anything related to libraries.
> > > 
> > > Best,
> > > Benito
> > > 
> > > 
> > > 
> > > On 05/07/2015 07:06 PM, Schwartz, Christine wrote:
> > > > I?m preparing an ALA preconference session for librarians 
> > > > titled ?Using XQuery as a Library Metadata Tool.? I?d like to 
> > > > provide the attendees with a list of XQuery resources so they 
> > > > can set up their own XQuery programming environment at their 
> > > > home institutions. Open source software is usually preferred 
> > > > by librarians,
> > > > especially for grant projects.
> > > > 
> > > > I feel a little handicapped in this area as I?ve been using
> > > > MarkLogic for over seven years and have not had to work with 
> > > > open source XQuery tools.
> > > > 
> > > > Any recommendations on what should be on this list?
> > > > 
> > > > Thanks,
> > > > 
> > > > Chris
> > > > 
> > > > Christine Schwartz
> > > > 
> > > > Metadata Librarian and XML Database Administrator
> > > > 
> > > > Princeton Theological Seminary Library
> > > > 
> > > > 25 Library Place
> > > > 
> > > > Princeton, NJ 08540
> > > > 
> > > >   christine.schwartz at ptsem.edu<mailto:
> > > > christine.schwartz at ptsem.edu>
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________ 
> > > > talk at x-query.com http://x-query.com/mailman/listinfo/talk
> > > _______________________________________________ talk at x-query.com 
> > > http://x-query.com/mailman/listinfo/talk
> > _______________________________________________ talk at x-query.com 
> > http://x-query.com/mailman/listinfo/talk
> 

From dflorescu at me.com  Sat May  9 11:31:45 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 11:31:45 -0700
Subject: [xquery-talk] Query 3.1 vs. JSONiq WAS Re: MarkLogic using JSONiq
 for processing JSON ?
In-Reply-To: <8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
Message-ID: <69764608-6EDF-429D-BF15-3249A38299C1@me.com>

Michael,

I think I didn?t make myself clear.

The purpose of a standard is to increase interoperability in the world.

The decisions that were taken in the case of XQuery 3.1 do exactly the opposite, WITHOUT bringing in any major technical 
advantages.

That?s all I am trying to say.

JSONiq is 3 years old, implemented by a variety of systems, and used in production in many places. And it was very well
designed: 2 years of VERY CAREFUL design by very good engineers went into the design of JSONiq. 

Plus JSONiq will CONTINUE to be used widely in the NOSQL community, simply for the following two reasons:
(a) it has a JSON-only subset that makes sense for the JSON-only community (who in general doesn?t want to see any shadow of angle brackets) and
(b) has the great advantage that doesn?t have the hated word ?Xquery? in its name.


By not following JSONiq, by taking ?slightly different? choices, or by not trying to extend it, XQuery 3.1 just broke the interoperability
in the NOSQL community, and this is what I consider a total lack of vision from the ?leaders? of this community.

Let?s look again of the differences you mentioned between JSONiq and XQuery 3.1. I quote:
***********************************************
At the data model level:

* Maps can use any atomic value as the key, it does not have to be a string
* The members of an array are sequences, not necessarily items
* JSON?s null is represented as an empty sequence, not as a new atomic data type

At the syntax level:

* In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
* XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1
**********************************************


Now, dear Michael, ask yourself the following questions:


*********************************************
1. Was there any ?mistake?, or ?bug?, that was in JSONiq that those choices solved ?  
I am not aware of any.

2. Are any of those choices ?fundamental?, aka introduce a much larger expressive power, make the language much easier to use, etc.?
Anything fundamental in those ?new? choices ? 
Nope, they are just small, mostly insignificant, just enough itsy bitsy differences to confuse and irritate the entire NoSQL community.

3. In case where a larger expressive power was desired, wasn?t it better to extend JSONiq in an upper compatible way, rather to take a different route ?

4. Did XQuery 3.1 ?committee? ever tried to contact the JSONiq community to try to find common solution that would eventual lead to a single, better language ?
ALL decisions we took in the design of JSONiq were definitely not random, but VERY carefully thought out. You were not even curious of what those reason where,
(and sometimes XQuery 3.1 got it totally wrong ? I an write you a long email about THAT).
*********************************************

So: no bugs to be fixed, no new major technical advantages, and no desire to cooperate.

What conclusion do you get from here ?

I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world. 

This can has two possible explanations: pure stupidity and lack of good will.

I am trying to be nice, and pick the second choice among those two?..you see. 

No wonder that because of silly decisions like this they will make XQuery to become irrelevant in the NoSQL world. No wonder the Cassandras, the Mongos
and the BigTable and all other JSON databases of the world will ignore what you ?decided?, deal Michael Kay and other W3C people.


And that?s a pity because  XQuery could have contributed quite a bit to the NoSQL world. XQuery has an experience of 16 years of processing semi-structured
data that those guys have no clue about (most they don?t even understand what they don?t know).

You made a HUGE political mistake in the design of XQuery 3.1. by fractioning the community.

And this: for no technical gain AT ALL.

The community looses, and I can see only two ?people? who beneficiate (only short term) from this schism: Saxon and MarkLogic.

Long term everyone looses from those stupid decisions.

Dana













> On May 8, 2015, at 4:09 AM, Michael Kay <mike at saxonica.com> wrote:
> 
>> 
>> So, to me,  the decisions of the W3C working group seems random, and rather based on a two years old
>> kind of a  tantrum ?I WANT TO BE DIFFERETENT JUST BECAUSE?..I WANT IT."
>> 
>> 
>> ??...rather then justified by any technical reasons.
>> 
> 
> No, all the arguments were all technical. For example:
> 
> * generalizing maps to allow any atomic type as the key, rather than only a string, was because of specific use cases that required this (remember that the first proposal to add maps to XDM came from XSLT streaming work, not from JSONiq)
> 
> * the decision to use ?map{?}? rather than ?{?}? was to some extent subjective, but was motivated by technical arguments such as the ability to produce good error messages, retaining options for future extensions to the grammar, etc. Expressions beginning with ?{? are particularly problematic because ?{? is used to delimit embedded expressions in element content, and ?{{? is used to escape ?{? as an ordinary character; they are also very obscure when used as the body of a function (declare function f {{1:2}}). Before making this decision, we looked at how many other popular languages solve this problem.
> 
> * the decision to allow any sequence to act as a member of an array enabled things like the fn:apply() function, whose second argument is an array of arbitrary sequences; it also enabled JSON null to be represented by an empty sequence, which avoided the need for pervasive changes to the language to define how every function and operator should handle a JSON null. Reducing the number of concepts by one is a definite plus.
> 
> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well. If there?s one aspect I?m still a little unhappy about, it?s the fact that an array behaves like a single item, so for example
> 
> let $A := [1,2,3]
> return $A[1]
> 
> returns [1,2,3]
> 
> But that?s there because we tried very hard to find a way to avoid this surprise, and failed: the sequence=item model in XDM is just too deeply embedded.
> 
> Michael Kay
> Saxonica
> 



From dflorescu at me.com  Sat May  9 11:44:09 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 11:44:09 -0700
Subject: [xquery-talk] Mistakes made in the design of XQuery 3.1
In-Reply-To: <69764608-6EDF-429D-BF15-3249A38299C1@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
Message-ID: <2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>

BTW, 

not only I don?t think that XQuery 3.1 didn?t bring any major technical advantage compared to JSONiq, I think some of the choices are simply
damn WRONG, and with long term negative consequences.

I can write a long email about that, but I don?t have time, and honestly, now I care more about Augmented Reality and 3D graphics
then I care about XML and JSON.

I will mention only the biggest mistake I see: the modeling of the JSON  NULL value as an empty sequence.

Do you really think we were silly in the design of JSONiq when we made it a separate value,  different from all other values !? No, we did it on purpose,
and with avery clear goal : to be able to control it?s semantics.

If you map the JSON NULL into the empty sequence, then the NULL will automatically behave in all operations (comparisons, arithmetics, etc)
as the empty sequence does in XQuery.

Unfortunately the semantics that XQuery has for the empty sequence is ***different*** from the semantics of NULL in the NATIVE language of JSON: Javascript.

Right there, by this ?small? decision, you made XQuery 3.1 unusable, hated, and unused in the Javascript community, and you made the XML
community to NOT be able to work together with the JSON community.


Great achievement, lots of thinking?..W3C people ?.. (it?s ironic..)

Dana



> On May 9, 2015, at 11:31 AM, daniela florescu <dflorescu at me.com> wrote:
> 
> Michael,
> 
> I think I didn?t make myself clear.
> 
> The purpose of a standard is to increase interoperability in the world.
> 
> The decisions that were taken in the case of XQuery 3.1 do exactly the opposite, WITHOUT bringing in any major technical 
> advantages.
> 
> That?s all I am trying to say.
> 
> JSONiq is 3 years old, implemented by a variety of systems, and used in production in many places. And it was very well
> designed: 2 years of VERY CAREFUL design by very good engineers went into the design of JSONiq. 
> 
> Plus JSONiq will CONTINUE to be used widely in the NOSQL community, simply for the following two reasons:
> (a) it has a JSON-only subset that makes sense for the JSON-only community (who in general doesn?t want to see any shadow of angle brackets) and
> (b) has the great advantage that doesn?t have the hated word ?Xquery? in its name.
> 
> 
> By not following JSONiq, by taking ?slightly different? choices, or by not trying to extend it, XQuery 3.1 just broke the interoperability
> in the NOSQL community, and this is what I consider a total lack of vision from the ?leaders? of this community.
> 
> Let?s look again of the differences you mentioned between JSONiq and XQuery 3.1. I quote:
> ***********************************************
> At the data model level:
> 
> * Maps can use any atomic value as the key, it does not have to be a string
> * The members of an array are sequences, not necessarily items
> * JSON?s null is represented as an empty sequence, not as a new atomic data type
> 
> At the syntax level:
> 
> * In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
> * XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1
> **********************************************
> 
> 
> Now, dear Michael, ask yourself the following questions:
> 
> 
> *********************************************
> 1. Was there any ?mistake?, or ?bug?, that was in JSONiq that those choices solved ?  
> I am not aware of any.
> 
> 2. Are any of those choices ?fundamental?, aka introduce a much larger expressive power, make the language much easier to use, etc.?
> Anything fundamental in those ?new? choices ? 
> Nope, they are just small, mostly insignificant, just enough itsy bitsy differences to confuse and irritate the entire NoSQL community.
> 
> 3. In case where a larger expressive power was desired, wasn?t it better to extend JSONiq in an upper compatible way, rather to take a different route ?
> 
> 4. Did XQuery 3.1 ?committee? ever tried to contact the JSONiq community to try to find common solution that would eventual lead to a single, better language ?
> ALL decisions we took in the design of JSONiq were definitely not random, but VERY carefully thought out. You were not even curious of what those reason where,
> (and sometimes XQuery 3.1 got it totally wrong ? I an write you a long email about THAT).
> *********************************************
> 
> So: no bugs to be fixed, no new major technical advantages, and no desire to cooperate.
> 
> What conclusion do you get from here ?
> 
> I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world. 
> 
> This can has two possible explanations: pure stupidity and lack of good will.
> 
> I am trying to be nice, and pick the second choice among those two?..you see. 
> 
> No wonder that because of silly decisions like this they will make XQuery to become irrelevant in the NoSQL world. No wonder the Cassandras, the Mongos
> and the BigTable and all other JSON databases of the world will ignore what you ?decided?, deal Michael Kay and other W3C people.
> 
> 
> And that?s a pity because  XQuery could have contributed quite a bit to the NoSQL world. XQuery has an experience of 16 years of processing semi-structured
> data that those guys have no clue about (most they don?t even understand what they don?t know).
> 
> You made a HUGE political mistake in the design of XQuery 3.1. by fractioning the community.
> 
> And this: for no technical gain AT ALL.
> 
> The community looses, and I can see only two ?people? who beneficiate (only short term) from this schism: Saxon and MarkLogic.
> 
> Long term everyone looses from those stupid decisions.
> 
> Dana
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On May 8, 2015, at 4:09 AM, Michael Kay <mike at saxonica.com> wrote:
>> 
>>> 
>>> So, to me,  the decisions of the W3C working group seems random, and rather based on a two years old
>>> kind of a  tantrum ?I WANT TO BE DIFFERETENT JUST BECAUSE?..I WANT IT."
>>> 
>>> 
>>> ??...rather then justified by any technical reasons.
>>> 
>> 
>> No, all the arguments were all technical. For example:
>> 
>> * generalizing maps to allow any atomic type as the key, rather than only a string, was because of specific use cases that required this (remember that the first proposal to add maps to XDM came from XSLT streaming work, not from JSONiq)
>> 
>> * the decision to use ?map{?}? rather than ?{?}? was to some extent subjective, but was motivated by technical arguments such as the ability to produce good error messages, retaining options for future extensions to the grammar, etc. Expressions beginning with ?{? are particularly problematic because ?{? is used to delimit embedded expressions in element content, and ?{{? is used to escape ?{? as an ordinary character; they are also very obscure when used as the body of a function (declare function f {{1:2}}). Before making this decision, we looked at how many other popular languages solve this problem.
>> 
>> * the decision to allow any sequence to act as a member of an array enabled things like the fn:apply() function, whose second argument is an array of arbitrary sequences; it also enabled JSON null to be represented by an empty sequence, which avoided the need for pervasive changes to the language to define how every function and operator should handle a JSON null. Reducing the number of concepts by one is a definite plus.
>> 
>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well. If there?s one aspect I?m still a little unhappy about, it?s the fact that an array behaves like a single item, so for example
>> 
>> let $A := [1,2,3]
>> return $A[1]
>> 
>> returns [1,2,3]
>> 
>> But that?s there because we tried very hard to find a way to avoid this surprise, and failed: the sequence=item model in XDM is just too deeply embedded.
>> 
>> Michael Kay
>> Saxonica
>> 
> 



From mike at saxonica.com  Sat May  9 12:50:00 2015
From: mike at saxonica.com (Michael Kay)
Date: Sat, 9 May 2015 20:50:00 +0100
Subject: [xquery-talk] Query 3.1 vs. JSONiq WAS Re: MarkLogic using
	JSONiq for processing JSON ?
In-Reply-To: <69764608-6EDF-429D-BF15-3249A38299C1@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
Message-ID: <B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>

That?s the standardisation process, unfortunately. It?s very rare for an existing design to be simply rubber-stamped by a standards committee. When SQL was standardized, ANSI didn?t simply rubber-stamp what IBM had done in System R.

What happens when you take a spec like JSONiq to a standards committee is that it gets scrutiny from a wider audience, some of whom want to address requirements that were outside the original scope. For some people, adding maps and arrays to XDM was more about increasing the expressive power of the language than specifically about supporting JSON; and the requirements for maps and arrays came from use cases other than JSON.

> 
> 
> JSONiq is 3 years old, implemented by a variety of systems, and used in production in many places. And it was very well
> designed: 2 years of VERY CAREFUL design by very good engineers went into the design of JSONiq. 

I agree, it was an excellent piece of work, that did what it set out to do extremely well.
> 
> Plus JSONiq will CONTINUE to be used widely in the NOSQL community, simply for the following two reasons:
> (a) it has a JSON-only subset that makes sense for the JSON-only community (who in general doesn?t want to see any shadow of angle brackets) and
> (b) has the great advantage that doesn?t have the hated word ?Xquery? in its name.

You may or may not be right, time will tell. I think it?s fairly inevitable that the user community addressed by the XQuery standards group will be the community that likes XQuery, not the community that hates it.
> 
> 
> By not following JSONiq, by taking ?slightly different? choices, or by not trying to extend it, XQuery 3.1 just broke the interoperability
> in the NOSQL community, and this is what I consider a total lack of vision from the ?leaders? of this community.

There were those on the committee who strongly defended the design choices that JSONiq had made. But no-one on the XQuery WG felt that the objective was to put a W3C stamp on work that had already been completed elsewhere.

Remember that JSONiq was not the only input to this work. The XSLT Working Group added maps to the XDM data model during 2010/2011 because they were needed for streaming use cases. During 2012 we become aware of the JSONiq work and attempted to bring the ideas into line; but we never considered dropping a feature (like using dates as keys in a map, or nodes as values) just because it wasn?t needed for JSON support.

> 
> Let?s look again of the differences you mentioned between JSONiq and XQuery 3.1. I quote:
> ***********************************************
> At the data model level:
> 
> * Maps can use any atomic value as the key, it does not have to be a string
> * The members of an array are sequences, not necessarily items
> * JSON?s null is represented as an empty sequence, not as a new atomic data type
> 
> At the syntax level:
> 
> * In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
> * XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1
> **********************************************
> 
> 
> Now, dear Michael, ask yourself the following questions:
> 
> 
> *********************************************
> 1. Was there any ?mistake?, or ?bug?, that was in JSONiq that those choices solved ?  
> I am not aware of any.

The differences were not motivated by fixing mistakes or bugs, but by addressing a wider range of use cases.
> 
> 2. Are any of those choices ?fundamental?, aka introduce a much larger expressive power, make the language much easier to use, etc.?
> Anything fundamental in those ?new? choices ? 
> Nope, they are just small, mostly insignificant, just enough itsy bitsy differences to confuse and irritate the entire NoSQL community.

I think the generalization of maps and arrays is rather fundamental, in that it increases the orthogonality of the data model. I cited the example of fn:apply(), which takes two arguments, a function and an array of arguments. Since each argument to a function is a sequence, we need a data structure which is an array (or sequence) of sequences, and limiting arrays to contain only items would have considerably reduced their power.

> 
> 3. In case where a larger expressive power was desired, wasn?t it better to extend JSONiq in an upper compatible way, rather to take a different route ?

Most of these differences were in fact compatible. Some were not, like using the map{} keyword. That was a carefully debated decision, but I don?t think an argument of compatibility with JSONiq would have carried much weight: for better or for worse, standardizing JSONiq wasn?t the group?s charter.
> 
> 4. Did XQuery 3.1 ?committee? ever tried to contact the JSONiq community to try to find common solution that would eventual lead to a single, better language ?

I think that the JSONiq developers were well represented in the discussions and argued their case vigorously, and often successfully. The XSL WG made a lot of changes/concessions during this process: in fact, everyone did.

> ALL decisions we took in the design of JSONiq were definitely not random, but VERY carefully thought out. You were not even curious of what those reason where,

No, that?s not true. I don?t know whether the ?you? here is referring to me personally, or to the group as a whole, but in both cases, it?s not true. Many arguments were aired in great detail and were heard with patience by all concerned.


> (and sometimes XQuery 3.1 got it totally wrong ? I an write you a long email about THAT).
> *********************************************
> 
> So: no bugs to be fixed, no new major technical advantages, and no desire to cooperate.

Getting to the point where we got to was not easy. There were passionate disagreements. The fact that we got a spec out is proof that everyone was trying to cooperate. Inevitably, not everyone will be happy with every decision that was made. Those who took part in the process are probably happier than those who did not, because they can see what the arguments were.

> 
> What conclusion do you get from here ?
> 
> I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world. 

Well you might be right there. Standards groups don?t really do vision and leadership: they argue about braces and semicolons.

> 
> This can has two possible explanations: pure stupidity and lack of good will.

No, I think it?s simply the result of having a variety of perspectives. Standards groups bring people together who have different ideas about what it is important to achieve, and the result always involves compromises, which not everyone will be happy with.
> 

Regards,
Michael Kay
Saxonica



From dflorescu at me.com  Sat May  9 13:46:05 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 13:46:05 -0700
Subject: [xquery-talk] Query 3.1 vs. JSONiq WAS Re: MarkLogic using
 JSONiq for processing JSON ?
In-Reply-To: <B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
Message-ID: <CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>


>> 
>> I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world. 
> 
> Well you might be right there. Standards groups don?t really do vision and leadership: they argue about braces and semicolons.


Michael,

I don?t get it.

You entire answer is telling me: "Standards groups don?t have (technical) vision and leadership."

That?s a HORRIBLE state of affairs, and I am surprised that this statement (that is indeed true) doesn?t shock you.

Then, how about they shut up and stop doing things, and imposing wrongly designed stuff on people. Or they could listen to people
who actually DO have technical vision and leadership !?

It seems that by ?doing? things the XQuery WG hurts more then by being quiet, and close down.

In particular, XQuery 3.1 is a failure because has NOT been designed with the major requirement in mind they should have had, which is:

***************************

Make BOTH communities happy:  XML and JSON, and help them work and integrate together. 
Help the (younger) JSON community learn from some of the lessons the (older) XML community learned in the past 16 years about querying 
and processing semi-strcutured data.

The world needs both, and the world needs them to work well together.

***************************


Why should some past choice made by XSLT in the past be more important then the goal I just stated ? in  big scheme of things !?


This is call short term thinking, and bad design.


Dana







From benito at benibela.de  Sat May  9 13:52:27 2015
From: benito at benibela.de (Benito van der Zander)
Date: Sat, 09 May 2015 22:52:27 +0200
Subject: [xquery-talk] Mistakes made in the design of XQuery 3.1
In-Reply-To: <2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
Message-ID: <554E738B.8050804@benibela.de>

Hi,
so many recipients. Tempting to add even more.

Too bad it was not discussed on these lists when XQuery 3.1 was still a 
draft.


I think the  array constructor was the biggest mistake. (I believe 
arrays more frequently used than null)
I doubt it would be possible to make a worse definition.

Three constructors, map { ... }, array { ... }, [ ... ]

Only [ ... ] looks out of place.

Every other constructor in XQuery uses { }. Even node constructors.

There is no reason to add [ .. ] for arrays, if you want to make a 
consistent language.
Especially adding [ ... ] but then not a raw { ... } for objects.


Anyways, assume someone really wants to have an abbreviation, because 
they like JSON or JSONiq.

How would you define the semantics of the constructors?

Use comma to separate members or as XQuery comma operator concatenating 
sequences?


What does it do in JSON?

There are no sequences

What does it do in JSONiq's [ ... ]?

It does concatenate sequences.

What does the other new constructor similar to array { } do ? map { 1 : 
(2,3), 4: (5,6) }

There , does not concatenate sequences.


So the only reasonable definition is to concat sequences in [ ] and not 
concatenate them in array { }


But no, you do the complete opposite!



Conclusion: The  [ .. ] constructor was just put there to annoy JSONiq 
users. That is the only explanation.

So an usual query that creates arrays cannot be a valid JSONiq and 
XQuery 3.1 query at the same time.



Best,
Benito



On 05/09/2015 08:44 PM, daniela florescu wrote:
> BTW,
>
> not only I don?t think that XQuery 3.1 didn?t bring any major technical advantage compared to JSONiq, I think some of the choices are simply
> damn WRONG, and with long term negative consequences.
>
> I can write a long email about that, but I don?t have time, and honestly, now I care more about Augmented Reality and 3D graphics
> then I care about XML and JSON.
>
> I will mention only the biggest mistake I see: the modeling of the JSON  NULL value as an empty sequence.
>
> Do you really think we were silly in the design of JSONiq when we made it a separate value,  different from all other values !? No, we did it on purpose,
> and with avery clear goal : to be able to control it?s semantics.
>
> If you map the JSON NULL into the empty sequence, then the NULL will automatically behave in all operations (comparisons, arithmetics, etc)
> as the empty sequence does in XQuery.
>
> Unfortunately the semantics that XQuery has for the empty sequence is ***different*** from the semantics of NULL in the NATIVE language of JSON: Javascript.
>
> Right there, by this ?small? decision, you made XQuery 3.1 unusable, hated, and unused in the Javascript community, and you made the XML
> community to NOT be able to work together with the JSON community.
>
>
> Great achievement, lots of thinking?..W3C people ?.. (it?s ironic..)
>
> Dana
>
>
>
>> On May 9, 2015, at 11:31 AM, daniela florescu <dflorescu at me.com> wrote:
>>
>> Michael,
>>
>> I think I didn?t make myself clear.
>>
>> The purpose of a standard is to increase interoperability in the world.
>>
>> The decisions that were taken in the case of XQuery 3.1 do exactly the opposite, WITHOUT bringing in any major technical
>> advantages.
>>
>> That?s all I am trying to say.
>>
>> JSONiq is 3 years old, implemented by a variety of systems, and used in production in many places. And it was very well
>> designed: 2 years of VERY CAREFUL design by very good engineers went into the design of JSONiq.
>>
>> Plus JSONiq will CONTINUE to be used widely in the NOSQL community, simply for the following two reasons:
>> (a) it has a JSON-only subset that makes sense for the JSON-only community (who in general doesn?t want to see any shadow of angle brackets) and
>> (b) has the great advantage that doesn?t have the hated word ?Xquery? in its name.
>>
>>
>> By not following JSONiq, by taking ?slightly different? choices, or by not trying to extend it, XQuery 3.1 just broke the interoperability
>> in the NOSQL community, and this is what I consider a total lack of vision from the ?leaders? of this community.
>>
>> Let?s look again of the differences you mentioned between JSONiq and XQuery 3.1. I quote:
>> ***********************************************
>> At the data model level:
>>
>> * Maps can use any atomic value as the key, it does not have to be a string
>> * The members of an array are sequences, not necessarily items
>> * JSON?s null is represented as an empty sequence, not as a new atomic data type
>>
>> At the syntax level:
>>
>> * In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
>> * XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1
>> **********************************************
>>
>>
>> Now, dear Michael, ask yourself the following questions:
>>
>>
>> *********************************************
>> 1. Was there any ?mistake?, or ?bug?, that was in JSONiq that those choices solved ?
>> I am not aware of any.
>>
>> 2. Are any of those choices ?fundamental?, aka introduce a much larger expressive power, make the language much easier to use, etc.?
>> Anything fundamental in those ?new? choices ?
>> Nope, they are just small, mostly insignificant, just enough itsy bitsy differences to confuse and irritate the entire NoSQL community.
>>
>> 3. In case where a larger expressive power was desired, wasn?t it better to extend JSONiq in an upper compatible way, rather to take a different route ?
>>
>> 4. Did XQuery 3.1 ?committee? ever tried to contact the JSONiq community to try to find common solution that would eventual lead to a single, better language ?
>> ALL decisions we took in the design of JSONiq were definitely not random, but VERY carefully thought out. You were not even curious of what those reason where,
>> (and sometimes XQuery 3.1 got it totally wrong ? I an write you a long email about THAT).
>> *********************************************
>>
>> So: no bugs to be fixed, no new major technical advantages, and no desire to cooperate.
>>
>> What conclusion do you get from here ?
>>
>> I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world.
>>
>> This can has two possible explanations: pure stupidity and lack of good will.
>>
>> I am trying to be nice, and pick the second choice among those two?..you see.
>>
>> No wonder that because of silly decisions like this they will make XQuery to become irrelevant in the NoSQL world. No wonder the Cassandras, the Mongos
>> and the BigTable and all other JSON databases of the world will ignore what you ?decided?, deal Michael Kay and other W3C people.
>>
>>
>> And that?s a pity because  XQuery could have contributed quite a bit to the NoSQL world. XQuery has an experience of 16 years of processing semi-structured
>> data that those guys have no clue about (most they don?t even understand what they don?t know).
>>
>> You made a HUGE political mistake in the design of XQuery 3.1. by fractioning the community.
>>
>> And this: for no technical gain AT ALL.
>>
>> The community looses, and I can see only two ?people? who beneficiate (only short term) from this schism: Saxon and MarkLogic.
>>
>> Long term everyone looses from those stupid decisions.
>>
>> Dana
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On May 8, 2015, at 4:09 AM, Michael Kay <mike at saxonica.com> wrote:
>>>
>>>> So, to me,  the decisions of the W3C working group seems random, and rather based on a two years old
>>>> kind of a  tantrum ?I WANT TO BE DIFFERETENT JUST BECAUSE?..I WANT IT."
>>>>
>>>>
>>>> ??...rather then justified by any technical reasons.
>>>>
>>> No, all the arguments were all technical. For example:
>>>
>>> * generalizing maps to allow any atomic type as the key, rather than only a string, was because of specific use cases that required this (remember that the first proposal to add maps to XDM came from XSLT streaming work, not from JSONiq)
>>>
>>> * the decision to use ?map{?}? rather than ?{?}? was to some extent subjective, but was motivated by technical arguments such as the ability to produce good error messages, retaining options for future extensions to the grammar, etc. Expressions beginning with ?{? are particularly problematic because ?{? is used to delimit embedded expressions in element content, and ?{{? is used to escape ?{? as an ordinary character; they are also very obscure when used as the body of a function (declare function f {{1:2}}). Before making this decision, we looked at how many other popular languages solve this problem.
>>>
>>> * the decision to allow any sequence to act as a member of an array enabled things like the fn:apply() function, whose second argument is an array of arbitrary sequences; it also enabled JSON null to be represented by an empty sequence, which avoided the need for pervasive changes to the language to define how every function and operator should handle a JSON null. Reducing the number of concepts by one is a definite plus.
>>>
>>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well. If there?s one aspect I?m still a little unhappy about, it?s the fact that an array behaves like a single item, so for example
>>>
>>> let $A := [1,2,3]
>>> return $A[1]
>>>
>>> returns [1,2,3]
>>>
>>> But that?s there because we tried very hard to find a way to avoid this surprise, and failed: the sequence=item model in XDM is just too deeply embedded.
>>>
>>> Michael Kay
>>> Saxonica
>>>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From mike at saxonica.com  Sat May  9 13:57:57 2015
From: mike at saxonica.com (Michael Kay)
Date: Sat, 9 May 2015 21:57:57 +0100
Subject: [xquery-talk] Mistakes made in the design of XQuery 3.1
In-Reply-To: <2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
Message-ID: <DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>

> 
> I will mention only the biggest mistake I see: the modeling of the JSON  NULL value as an empty sequence.
> 
> Do you really think we were silly in the design of JSONiq when we made it a separate value,  different from all other values !? No, we did it on purpose,
> and with avery clear goal : to be able to control it?s semantics.
> 
> If you map the JSON NULL into the empty sequence, then the NULL will automatically behave in all operations (comparisons, arithmetics, etc)
> as the empty sequence does in XQuery.
> 

You can be assured that we had lively debates on this topic, and there were good arguments to be made both ways: none of them at all silly.

The use of empty sequence to represent absence of a value is very pervasive across all the functions and operators of the language. Many people felt that having two different ways to represent the absence of a value would just be too bewildering and too complex, and that few users would understand the subtle differences between them. If null can be supplied as an operand to comparisons, arithmetics, and to functions, then we not only need to define what every function and operator does when null is passed, we probably need to extend the type system so a function signature can declare that an argument is ?nullable xs:integer? (i.e. the union of xs:integer and null), and we then have to teach users the difference between xs:integer? and ?nullable xs:integer?. You even have to consider the type null? which is either null or empty. And we would almost inevitably have some functions returning () and others returning null to mean essentially the same thing - no result. People would have to check the spec every time they can?t remember which variety of null a particular function uses.

We were aware, also, that XQuery has two equality operators, and Javascript also has two, and none of them quite do the same thing. We didn?t want four equality operators. Unambiguous mapping of the JSON data model to XDM was an objective, but replication of the semantics of Javascript operators wasn?t.

Michael Kay
Saxonica





From mike at saxonica.com  Sat May  9 14:22:40 2015
From: mike at saxonica.com (Michael Kay)
Date: Sat, 9 May 2015 22:22:40 +0100
Subject: [xquery-talk] Mistakes made in the design of XQuery 3.1
In-Reply-To: <554E738B.8050804@benibela.de>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<554E738B.8050804@benibela.de>
Message-ID: <A36FB2AD-4A28-4B27-A37A-9650840CC995@saxonica.com>

> 
> I think the  array constructor was the biggest mistake. (I believe arrays more frequently used than null)
> I doubt it would be possible to make a worse definition.
> 
> Three constructors, map { ... }, array { ... }, [ ... ]
> 
> Only [ ... ] looks out of place.
> 
> Every other constructor in XQuery uses { }. Even node constructors.
> 
> There is no reason to add [ .. ] for arrays, if you want to make a consistent language.

I agree with you, I?m not happy with this aspect of the design. But the decision was reached after lengthy arguments at a F2F meeting which I didn?t attend, so I couldn?t complain.

The problem is that neither construct does the whole job. [a,b,c] can only be used to create an array whose size is statically known, whereas array{X,Y,Z} can only be used to create an array whose members are single items.

But the underlying problem is really that arrays are second-class citizens in the language. FLWOR expressions, filter expressions, even the comma operator, work on sequences but not on arrays. We tried many different design approaches for arrays in attempting to tackle this problem, but this was the best we could do.

> 
> So the only reasonable definition is to concat sequences in [ ] and not concatenate them in array { }
> 
> 
> But no, you do the complete opposite!
> 

Yes. I tried to get it changed to be the other way around, and failed. Just in case Daniela thinks I got everything my way.

Michael Kay
Saxonica

From dflorescu at me.com  Sat May  9 14:25:04 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 14:25:04 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
Message-ID: <AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>

>> 
> 
> You can be assured that we had lively debates on this topic,

After ?living? in the XQuery W3C working group for 15 years?.. I don?t doubt you had. I am just happy I was not there.

But, sorry, W3C took the wrong decision: in one instant with this decision, you lost the JSON community.


> and there were good arguments to be made both ways: none of them at all silly.
> 
> We were aware, also, that XQuery has two equality operators, and Javascript also has two, and none of them quite do the same thing. We didn?t want four equality operators. 

Do you really think that XQuery has only TWO equality operators ? 

No. Only two are in the external syntax. Every user I know of XQuery adds more as functions, depending to his/her own application needs.

So, two, four, six, ten, what?s the difference ? (it?s like that saying ?the wife had only two lovers..it?s not that bad..four would have been really bad...? )

When you see that it is more then two, three, then you make it parametrable.

Making null a separate value would have enabled any programming language which is a consumer of JSON (and they ALL are..) to add their OWN semantics, 
according to their wishes.

It?s called flexibility, and making things parametrable, (especially for something as important as equality for semi-structured data, whose semantics is in the eye of the beholder),
instead of rigid, monolithic, authocratic design, which invariably makes 90% users unhappy.


But that?s only one of the things that I think XQuery 3.1 got wrong. There are others.


The major OTHER problem is that it hadn?t been designed (as JSONiq did..) to be a syntactic superset of XQuery 3.0 , but which can be subsetted NICELY into a 
JSON-only language that would have been syntactically and semantically pleasant to a JSON-only community.


For JSONiq this was one of the major, major design goals.


Too bad, because such W3C decisions have implications on splitting the XML and JSON communities, and THAT, has implications on decades of technology??and billions
of dollars lost in industry by unnecessary frictions and fragmentation of the market.


Dana




From mike at saxonica.com  Sat May  9 14:51:24 2015
From: mike at saxonica.com (Michael Kay)
Date: Sat, 9 May 2015 22:51:24 +0100
Subject: [xquery-talk] Query 3.1 vs. JSONiq WAS Re: MarkLogic using
	JSONiq for processing JSON ?
In-Reply-To: <CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
Message-ID: <05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>


> On 9 May 2015, at 21:46, daniela florescu <dflorescu at me.com> wrote:
> 
> 
>>> 
>>> I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world. 
>> 
>> Well you might be right there. Standards groups don?t really do vision and leadership: they argue about braces and semicolons.
> 
> 
> Michael,
> 
> I don?t get it.
> 
> You entire answer is telling me: "Standards groups don?t have (technical) vision and leadership."
> 
> That?s a HORRIBLE state of affairs, and I am surprised that this statement (that is indeed true) doesn?t shock you.

Standards groups spend their time hammering out compromises to reconcile different visions. The result is very often a compromise. If they get it right, the result is a specification that meets a wider range of requirements and is acceptable to a wider community. But very few standards are noted for technical elegance.

> 
> Then, how about they shut up and stop doing things, and imposing wrongly designed stuff on people. Or they could listen to people
> who actually DO have technical vision and leadership !?

Reminds me of my first XQuery group meeting: I was shocked by how many highly talented people there were with good ideas, all wanting to take it in different directions.
> 
> It seems that by ?doing? things the XQuery WG hurts more then by being quiet, and close down.
> 
> In particular, XQuery 3.1 is a failure because has NOT been designed with the major requirement in mind they should have had, which is:
> 
> ***************************
> 
> Make BOTH communities happy:  XML and JSON, and help them work and integrate together. 
> 

We definitely had people on the working group with the ambition to create a query language suitable for either XML or JSON as equal partners. Others felt that that was an unrealistic goal, and that XQuery should remain an XML query language with the ability to interoperate with JSON (and other formats) as second-class citizens. If you?re going to get anywhere in standards work, you have to appreciate that there?s going to be more than one vision, and that none of them are self-evidently right or wrong.

> Why should some past choice made by XSLT in the past be more important then the goal I just stated ? in  big scheme of things !?
> 
> 
See above. You get inputs from lots of different directions, and they are all valid perspectives.

Michael Kay
Saxonica





From dflorescu at me.com  Sat May  9 15:00:54 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 15:00:54 -0700
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
Message-ID: <4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>

>> 
> See above. You get inputs from lots of different directions, and they are all valid perspectives.


Com? on MIchael. Stop running around the bush. I hate hypocrisy in technology.

Botton line is: as a result of what W3C did with XQuery 3.1, they created more harm them good overall for the industry.


And this:  for both the XML community  AND  the JSON community.

For the XML community: they?ll be hated and avoided even more they used to be, and more and more isolated, and
For the JSON community:  they?ll avoid anything related to XQuery like scary evil, which means that they?ll design silly query languages 
by themselves (see Cassandra, see Mongo, see BigTable?.)  for 15 years  before finding some decent solution.


Great.

Thanks for your contribution.

Dana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150509/98d39c03/attachment.html>

From dflorescu at me.com  Sat May  9 16:41:17 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 16:41:17 -0700
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
Message-ID: <09E024AB-C01F-4498-A274-740A1D380723@me.com>

Adam, Ghislain,


Com? on. Stop running around the bush. I hate hypocrisy in technology.
Reading your emails made me feel back in the communist era, with the perfect usage of a perfect wooden language.

Since when ?working well together? and ?listening to each other? (what a wonderful world !!!!)?..: guaranteed a good technical result !???
(Maybe they should have voted to see if Galileo was right or not ?. wait, actually they DID?. OUPS.)

Since when this guaranteed any logical result, and any good, usable tool for an industry !? 
(Web services would be the first thing that would jump to my mind as a graceful design of a ?nice" community that all listened to each other
? as a nightmare equivalent to XQuery 3.1)

More often then not, such a ?nice process? ends up in a horrible technical compromise which is good for no-one, and gets abandoned 
by industry VERY, VERY soon.

============


You both prove my point: the design of XQuery 3.1 was done to ?help? selfishly and with a very short term vision two-three companies (Saxon, Exist, MarkLogic), and with complete
disregard to the big picture of the needs of querying and processing semi-structured data in the industry (which includes both XML and JSON).

As for the choice between solving:
(a) XSLT maps and arrays (estimated # use cases in the Ks, includes all three eXist, Saxon and MarkLogic) and 
(b) querying JSON (downloads of Mongo+Cassandra+Cloudera+Spark+Couch+?    in the tens of millions of downloads?)


(let alone the comparison in the total sales number?)

??...very intelligently, XQuery 3.1 decided to totally ignore the millions of use cases of Cassandra+Mongo+Cloudera+?., and ?serve? Saxon and eXist,
and antagonize all those millions of use cases that need JSON query processing.

Again.

Great.

Thanks for your ?contribution" to the industry. 


Dana



> On May 8, 2015, at 4:21 AM, Adam Retter <adam.retter at googlemail.com> wrote:
> 
>> No, all the arguments were all technical
>> 
>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well.
> 
> Absolutely! Whilst I am more of an occasional frequenter and
> contributor to the XQuery WG, having seen the level of collaborative
> work and perseverance that that has gone into adding Maps and Arrays
> to XQuery, I can say that I am impressed.
> 
> From my perspective, it was a difficult process, but everyone worked
> hard together and the technical arguments were always foremost. Whilst
> working under the constraints of backwards compatibility and creating
> a cohesive data model and language, I think the result speaks for
> itself. Certainly many of eXist's users are very happy with the new
> Maps and Arrays work in XQuery 3.1 and we frequently receive positive
> feedback on this.
> 
> 
> 
> -- 
> Adam Retter
> 
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk



From adam.retter at googlemail.com  Sat May  9 16:42:09 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Sun, 10 May 2015 00:42:09 +0100
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
	<4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
Message-ID: <CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>

> Botton line is: as a result of what W3C did with XQuery 3.1, they created
> more harm them good overall for the industry.
>
>
> And this:  for both the XML community  AND  the JSON community.
>
> For the XML community: they?ll be hated and avoided even more they used to
> be, and more and more isolated, and

I don't understand your perspective at all.
I don't believe that XQuery is perfect, but then I don't believe that
any other programming or query language is either. Significantly
however we do have real XQuery 3.1 users (that were previously using
XQuery 3.0 and XQuery 1.0) publicly thanking us for the new features
of XQuery 3.1 that they are enjoying, here is one such recent thank
you - http://exist.markmail.org/thread/mb7jdspx5h3d67kj


> For the JSON community:  they?ll avoid anything related to XQuery like scary
> evil, which means that they?ll design silly query languages
> by themselves (see Cassandra, see Mongo, see BigTable?.)  for 15 years
> before finding some decent solution.

JSON is important sure, but I don't believe it is the beginning and
the end of the Web and/or NoSQL. You mention Cassandra, but their
query language CQL appears to me to be inspired by SQL rather than
anything like JSONiq.

I really like JSONiq, I even started an implementation (unfinished) a
few years back. However, I have no sympathy for people or communities
that want to ignore a technology base because it is `scary evil`, I
don't buy into that as an argument, it just sounds like FUD; Serious
implementers of any language will always do their homework and learn
about the best and worst of their predecessors.

Regards Mongo, the only JSONiq implementation for that seems to be
from 28msec which you were heavily involved in I believe. Outside of
28msec and their partner work (IBM), apart from Xidel, I have not seen
any implementations of JSONiq. Certainly the NoSQL databases that you
mention, don't require a W3C stamped query language for them to
produce an implementation. I would be genuinely interested to know why
JSONiq was not more widely adopted? I really believed that JSONiq
would be snapped up very quickly by NoSQL JSON/BSON stores, Node.js
and others.

I think that if people want just a JavaScript query language for JSON
then why don't they just get/create an implementation of JSONiq in
JavaScript? Sure it could have been XQuery 3.1, but it's not... and
well... I think that is okay. XQuery 3.1 has its own use-cases and
purpose, it might not be as popular as JSON, but I don't see that as
an issue, they solve different (and sometimes similar) problems.



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk


From dflorescu at me.com  Sat May  9 16:44:18 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 16:44:18 -0700
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
	<4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
	<CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>
Message-ID: <83FE05C5-2C9C-4474-BC81-DEF8560BF41B@me.com>

Adam,

sorry, will not respond this thread from now on. It?s a waste of my time.

Best
Dana




> On May 9, 2015, at 4:42 PM, Adam Retter <adam.retter at googlemail.com> wrote:
> 
>> Botton line is: as a result of what W3C did with XQuery 3.1, they created
>> more harm them good overall for the industry.
>> 
>> 
>> And this:  for both the XML community  AND  the JSON community.
>> 
>> For the XML community: they?ll be hated and avoided even more they used to
>> be, and more and more isolated, and
> 
> I don't understand your perspective at all.
> I don't believe that XQuery is perfect, but then I don't believe that
> any other programming or query language is either. Significantly
> however we do have real XQuery 3.1 users (that were previously using
> XQuery 3.0 and XQuery 1.0) publicly thanking us for the new features
> of XQuery 3.1 that they are enjoying, here is one such recent thank
> you - http://exist.markmail.org/thread/mb7jdspx5h3d67kj
> 
> 
>> For the JSON community:  they?ll avoid anything related to XQuery like scary
>> evil, which means that they?ll design silly query languages
>> by themselves (see Cassandra, see Mongo, see BigTable?.)  for 15 years
>> before finding some decent solution.
> 
> JSON is important sure, but I don't believe it is the beginning and
> the end of the Web and/or NoSQL. You mention Cassandra, but their
> query language CQL appears to me to be inspired by SQL rather than
> anything like JSONiq.
> 
> I really like JSONiq, I even started an implementation (unfinished) a
> few years back. However, I have no sympathy for people or communities
> that want to ignore a technology base because it is `scary evil`, I
> don't buy into that as an argument, it just sounds like FUD; Serious
> implementers of any language will always do their homework and learn
> about the best and worst of their predecessors.
> 
> Regards Mongo, the only JSONiq implementation for that seems to be
> from 28msec which you were heavily involved in I believe. Outside of
> 28msec and their partner work (IBM), apart from Xidel, I have not seen
> any implementations of JSONiq. Certainly the NoSQL databases that you
> mention, don't require a W3C stamped query language for them to
> produce an implementation. I would be genuinely interested to know why
> JSONiq was not more widely adopted? I really believed that JSONiq
> would be snapped up very quickly by NoSQL JSON/BSON stores, Node.js
> and others.
> 
> I think that if people want just a JavaScript query language for JSON
> then why don't they just get/create an implementation of JSONiq in
> JavaScript? Sure it could have been XQuery 3.1, but it's not... and
> well... I think that is okay. XQuery 3.1 has its own use-cases and
> purpose, it might not be as popular as JSON, but I don't see that as
> an issue, they solve different (and sometimes similar) problems.
> 
> 
> 
> -- 
> Adam Retter
> 
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk



From adam.retter at googlemail.com  Sat May  9 17:03:36 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Sun, 10 May 2015 01:03:36 +0100
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <09E024AB-C01F-4498-A274-740A1D380723@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
	<09E024AB-C01F-4498-A274-740A1D380723@me.com>
Message-ID: <CAPK0icjHdyuwJUtbQC7fT98_pE3xU0FJDU08R=v6_ZCC-22Sug@mail.gmail.com>

Hi Daniela,

I am not sure if I need to, but I feel that I might need to defend
myself from your latest email.

Let me be clear, I personally wanted to participate in the XQuery WG.
I was not asked to do it by anyone in the eXist project and neither
did I do it to advance the eXist project. My sole purpose at the time
for enquiring about how I might join without working for a member
organisation of the W3C was because I felt that open source community
implementations of XQuery were unrepresented within the working group.
I felt that the average user of XQuery, that could not afford an
expensive implementation should also be represented within the WG.

I was lucky to be invited to join the WG and I am thankful for that.
Subsequently, I have paid out of my own personal pocket for every WG
meeting I have attended. I can only attend those in Europe as the
others further afield are beyond my means, and I have not always been
able to attend all in Europe due to cost. I work on an Open Source
project, almost all of the work I do is unfunded and I do it in my
evenings and weekends because it is interesting and I enjoy
contributing to the community. I did email the FLWOR Foundation about
possible funding on more than one occasion in the past but never
received a response from you. I have never been paid in any way for my
WG efforts or reimbursed any of my costs by any organisation (that
includes eXist Solutions).

What I am trying to say, is that I am not part of the WG to achieve
some sort of eXist-db domination plan, or for any sort of
machiavellian scheme. I attend the WG meetings because I genuinely
want to improve the language for its users, and for me that is more
important than what eXist, BaseX, MarkLogic, IBM, Oracle or any other
implementation wants. I also teach several XQuery courses each year
entirely free of charge, and again I fund this out of my own pocket,
my goal as always is to help the community. I think that XQuery is a
beautiful language that brings a great deal of freedom to its users.

I understand that you are unhappy with the design of XQuery 3.1, and I
am sorry to hear that; I know that you were deeply instrumental in the
original design of XQuery and spent many years working on the XQuery
WG.

All the best. Adam.

On 10 May 2015 at 00:41, daniela florescu <dflorescu at me.com> wrote:
> Adam, Ghislain,
>
>
> Com? on. Stop running around the bush. I hate hypocrisy in technology.
> Reading your emails made me feel back in the communist era, with the perfect usage of a perfect wooden language.
>
> Since when ?working well together? and ?listening to each other? (what a wonderful world !!!!)?..: guaranteed a good technical result !???
> (Maybe they should have voted to see if Galileo was right or not ?. wait, actually they DID?. OUPS.)
>
> Since when this guaranteed any logical result, and any good, usable tool for an industry !?
> (Web services would be the first thing that would jump to my mind as a graceful design of a ?nice" community that all listened to each other
> ? as a nightmare equivalent to XQuery 3.1)
>
> More often then not, such a ?nice process? ends up in a horrible technical compromise which is good for no-one, and gets abandoned
> by industry VERY, VERY soon.
>
> ============
>
>
> You both prove my point: the design of XQuery 3.1 was done to ?help? selfishly and with a very short term vision two-three companies (Saxon, Exist, MarkLogic), and with complete
> disregard to the big picture of the needs of querying and processing semi-structured data in the industry (which includes both XML and JSON).
>
> As for the choice between solving:
> (a) XSLT maps and arrays (estimated # use cases in the Ks, includes all three eXist, Saxon and MarkLogic) and
> (b) querying JSON (downloads of Mongo+Cassandra+Cloudera+Spark+Couch+?    in the tens of millions of downloads?)
>
>
> (let alone the comparison in the total sales number?)
>
> ??...very intelligently, XQuery 3.1 decided to totally ignore the millions of use cases of Cassandra+Mongo+Cloudera+?., and ?serve? Saxon and eXist,
> and antagonize all those millions of use cases that need JSON query processing.
>
> Again.
>
> Great.
>
> Thanks for your ?contribution" to the industry.
>
>
> Dana
>
>
>
>> On May 8, 2015, at 4:21 AM, Adam Retter <adam.retter at googlemail.com> wrote:
>>
>>> No, all the arguments were all technical
>>>
>>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well.
>>
>> Absolutely! Whilst I am more of an occasional frequenter and
>> contributor to the XQuery WG, having seen the level of collaborative
>> work and perseverance that that has gone into adding Maps and Arrays
>> to XQuery, I can say that I am impressed.
>>
>> From my perspective, it was a difficult process, but everyone worked
>> hard together and the technical arguments were always foremost. Whilst
>> working under the constraints of backwards compatibility and creating
>> a cohesive data model and language, I think the result speaks for
>> itself. Certainly many of eXist's users are very happy with the new
>> Maps and Arrays work in XQuery 3.1 and we frequently receive positive
>> feedback on this.
>>
>>
>>
>> --
>> Adam Retter
>>
>> skype: adam.retter
>> tweet: adamretter
>> http://www.adamretter.org.uk
>



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk


From dflorescu at me.com  Sat May  9 21:42:47 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 21:42:47 -0700
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <CAPK0icjHdyuwJUtbQC7fT98_pE3xU0FJDU08R=v6_ZCC-22Sug@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
	<09E024AB-C01F-4498-A274-740A1D380723@me.com>
	<CAPK0icjHdyuwJUtbQC7fT98_pE3xU0FJDU08R=v6_ZCC-22Sug@mail.gmail.com>
Message-ID: <FB2655B3-2A41-4A07-AE98-B1C3793D9FE6@me.com>

Well, Adam, I can look only at the results of those efforts, and judge by the results, sorry. I?m not a mind reader.

I offered two possible explanations fort such a strange outcome as XQuery 3.1 (it?s not an ostrich, and it?s not
a camel, but kind of looks like both).

I said: 

       "This can have two possible explanations: pure stupidity and lack of good will.?

Ok. I can add another one: technical and political naivety.

Best regards
Dana






> On May 9, 2015, at 5:03 PM, Adam Retter <adam.retter at googlemail.com> wrote:
> 
> Hi Daniela,
> 
> I am not sure if I need to, but I feel that I might need to defend
> myself from your latest email.
> 
> Let me be clear, I personally wanted to participate in the XQuery WG.
> I was not asked to do it by anyone in the eXist project and neither
> did I do it to advance the eXist project. My sole purpose at the time
> for enquiring about how I might join without working for a member
> organisation of the W3C was because I felt that open source community
> implementations of XQuery were unrepresented within the working group.
> I felt that the average user of XQuery, that could not afford an
> expensive implementation should also be represented within the WG.
> 
> I was lucky to be invited to join the WG and I am thankful for that.
> Subsequently, I have paid out of my own personal pocket for every WG
> meeting I have attended. I can only attend those in Europe as the
> others further afield are beyond my means, and I have not always been
> able to attend all in Europe due to cost. I work on an Open Source
> project, almost all of the work I do is unfunded and I do it in my
> evenings and weekends because it is interesting and I enjoy
> contributing to the community. I did email the FLWOR Foundation about
> possible funding on more than one occasion in the past but never
> received a response from you. I have never been paid in any way for my
> WG efforts or reimbursed any of my costs by any organisation (that
> includes eXist Solutions).
> 
> What I am trying to say, is that I am not part of the WG to achieve
> some sort of eXist-db domination plan, or for any sort of
> machiavellian scheme. I attend the WG meetings because I genuinely
> want to improve the language for its users, and for me that is more
> important than what eXist, BaseX, MarkLogic, IBM, Oracle or any other
> implementation wants. I also teach several XQuery courses each year
> entirely free of charge, and again I fund this out of my own pocket,
> my goal as always is to help the community. I think that XQuery is a
> beautiful language that brings a great deal of freedom to its users.
> 
> I understand that you are unhappy with the design of XQuery 3.1, and I
> am sorry to hear that; I know that you were deeply instrumental in the
> original design of XQuery and spent many years working on the XQuery
> WG.
> 
> All the best. Adam.
> 
> On 10 May 2015 at 00:41, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> Adam, Ghislain,
>> 
>> 
>> Com? on. Stop running around the bush. I hate hypocrisy in technology.
>> Reading your emails made me feel back in the communist era, with the perfect usage of a perfect wooden language.
>> 
>> Since when ?working well together? and ?listening to each other? (what a wonderful world !!!!)?..: guaranteed a good technical result !???
>> (Maybe they should have voted to see if Galileo was right or not ?. wait, actually they DID?. OUPS.)
>> 
>> Since when this guaranteed any logical result, and any good, usable tool for an industry !?
>> (Web services would be the first thing that would jump to my mind as a graceful design of a ?nice" community that all listened to each other
>> ? as a nightmare equivalent to XQuery 3.1)
>> 
>> More often then not, such a ?nice process? ends up in a horrible technical compromise which is good for no-one, and gets abandoned
>> by industry VERY, VERY soon.
>> 
>> ============
>> 
>> 
>> You both prove my point: the design of XQuery 3.1 was done to ?help? selfishly and with a very short term vision two-three companies (Saxon, Exist, MarkLogic), and with complete
>> disregard to the big picture of the needs of querying and processing semi-structured data in the industry (which includes both XML and JSON).
>> 
>> As for the choice between solving:
>> (a) XSLT maps and arrays (estimated # use cases in the Ks, includes all three eXist, Saxon and MarkLogic) and
>> (b) querying JSON (downloads of Mongo+Cassandra+Cloudera+Spark+Couch+?    in the tens of millions of downloads?)
>> 
>> 
>> (let alone the comparison in the total sales number?)
>> 
>> ??...very intelligently, XQuery 3.1 decided to totally ignore the millions of use cases of Cassandra+Mongo+Cloudera+?., and ?serve? Saxon and eXist,
>> and antagonize all those millions of use cases that need JSON query processing.
>> 
>> Again.
>> 
>> Great.
>> 
>> Thanks for your ?contribution" to the industry.
>> 
>> 
>> Dana
>> 
>> 
>> 
>>> On May 8, 2015, at 4:21 AM, Adam Retter <adam.retter at googlemail.com> wrote:
>>> 
>>>> No, all the arguments were all technical
>>>> 
>>>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well.
>>> 
>>> Absolutely! Whilst I am more of an occasional frequenter and
>>> contributor to the XQuery WG, having seen the level of collaborative
>>> work and perseverance that that has gone into adding Maps and Arrays
>>> to XQuery, I can say that I am impressed.
>>> 
>>> From my perspective, it was a difficult process, but everyone worked
>>> hard together and the technical arguments were always foremost. Whilst
>>> working under the constraints of backwards compatibility and creating
>>> a cohesive data model and language, I think the result speaks for
>>> itself. Certainly many of eXist's users are very happy with the new
>>> Maps and Arrays work in XQuery 3.1 and we frequently receive positive
>>> feedback on this.
>>> 
>>> 
>>> 
>>> --
>>> Adam Retter
>>> 
>>> skype: adam.retter
>>> tweet: adamretter
>>> http://www.adamretter.org.uk
>> 
> 
> 
> 
> -- 
> Adam Retter
> 
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk <http://www.adamretter.org.uk/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150509/3301a6f4/attachment.html>

From dflorescu at me.com  Sat May  9 21:49:48 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 09 May 2015 21:49:48 -0700
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <CAPa8FbRLGwy3sNPEF7dA_rRa8=TOx2hJUZ6Gdogm8obP-88u_g@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
	<CAPa8FbRLGwy3sNPEF7dA_rRa8=TOx2hJUZ6Gdogm8obP-88u_g@mail.gmail.com>
Message-ID: <6823E8E7-59F0-4F71-9815-BF453661B332@me.com>

Ghislain,

just a simple remark about the hypocrisy and/or naivety and/or lack of technical skills in the design of XQuery 3.1.

You say that , unlike JSONiq, it?s NOT designed as a query language for JSON, and that?s why it fails so short in that respect.

If it is NOT designed as a query language for JSON, why did you bother introducing the notion of the JSON nulll  in XQuery 3.1 at all !?
(I mean, why not the null pointer from Java !??? Or some Scala structures !??)

Pick your choose: 
- either XQuery 3.1 was intended to query JSON, and then it failed, or
- XQuery 3.1 was NOT intended to query JSON, and then it?s damn weird.


Dana




> On May 8, 2015, at 5:46 AM, Ghislain Fourny <g at 28.io> wrote:
> 
> Hi,
> 
> My understanding of the reason why XQuery 3.1 and JSONiq diverge is
> also use-case based. If you are interested in some more background, I
> believe there were two drivers all along:
> 
> 1. Support for NoSQL document store querying.
> 2. Support for map and array structures in memory.
> 
> Both use cases are important, even if their importance varies from
> project to project or from company to company.
> 
> JSONiq was designed 100% for NoSQL document store querying : it is (on
> purpose) optimized for supporting use case 1 and only use case 1.
> 
> XQuery 3.1 also covers use case 2. Supporting both use cases and
> making compromises between the two was not trivial, which is why there
> was a lot of work put into the discussions and the design in the
> working group.
> 
> I share Adam's feeling 100%. Everybody took the time to patiently
> listen to one another, which is one of the aspects of the working
> group I valued the most. I enjoyed each meeting we had and learned a
> lot from the discussions -- paradoxically, I also had the feeling of
> knowing JSONiq better after having them.
> 
> To me, one of the main concrete technical differences (if I correctly
> remember) is that JSONiq manipulates trees/documents (both with XML
> and JSON), so that when you put data into an object, it is copied over
> (even if most of the time the optimizer can spare the actual copying).
> This eliminates many serialization issues when data gets roundtripped
> around. XQuery 3.1 is more data-structure oriented as use case 2
> requires retaining the original identity of map and array values,
> which theoretically allows graphs. This difference is important and
> noticeable when updates and scripting kick in.
> 
> Of course, for each set of use cases, standards and interoperability
> are always desirable, so I can understand Dana's discomfort. I also
> think, though, that it is natural for different languages to emerge if
> the use cases differ and, in the broader context of IT, think that it
> is wise to pragmatically select technologies based on what one wants
> to achieve.
> 
> On the bright side also: the data models behind the languages are
> similar, and both languages can run on the same virtual machine. Zorba
> already supports XQuery 3.0 and JSONiq side by side.
> 
> I hope it makes sense.
> 
> Kind regards,
> Ghislain
> 
> 
> On Fri, May 8, 2015 at 1:21 PM, Adam Retter <adam.retter at googlemail.com> wrote:
>>> No, all the arguments were all technical
>>> 
>>> Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well.
>> 
>> Absolutely! Whilst I am more of an occasional frequenter and
>> contributor to the XQuery WG, having seen the level of collaborative
>> work and perseverance that that has gone into adding Maps and Arrays
>> to XQuery, I can say that I am impressed.
>> 
>> From my perspective, it was a difficult process, but everyone worked
>> hard together and the technical arguments were always foremost. Whilst
>> working under the constraints of backwards compatibility and creating
>> a cohesive data model and language, I think the result speaks for
>> itself. Certainly many of eXist's users are very happy with the new
>> Maps and Arrays work in XQuery 3.1 and we frequently receive positive
>> feedback on this.
>> 
>> 
>> 
>> --
>> Adam Retter
>> 
>> skype: adam.retter
>> tweet: adamretter
>> http://www.adamretter.org.uk
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From wcandillon at gmail.com  Sun May 10 00:42:20 2015
From: wcandillon at gmail.com (William Candillon)
Date: Sun, 10 May 2015 00:42:20 -0700
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <83FE05C5-2C9C-4474-BC81-DEF8560BF41B@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
	<4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
	<CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>
	<83FE05C5-2C9C-4474-BC81-DEF8560BF41B@me.com>
Message-ID: <CAM7ytN9Bz0y20DhYjf+oq91fd2dhoEqa8EaQUU8xALf7wmYwaA@mail.gmail.com>

Hi Adam,

To answer your last question, there is a typescript implementation of
JSONiq that started here: https://github.com/wcandillon/jsoniq.
It will be interesting to see the reception in the NoSQL and HTML5
community when this project will be a bit more mature.

It implements JSONiq updates and update composition on top of
IndexedDB. The end goal is to query/update IndexedDB and implement a
versioning system between IndexedDB and the cloud. Compiled queries
can run as standalone JavaScript programs: it's very lightweight.
It is tested against both browsers and nodejs.

This implementation is 100% organically grown.  We started with an
XQuery parser in JavaScript for HTML5 editors. We then added static
analysis for errors and warnings (XQLint). XQLint is quite mature now
and the next logical step was to add a code generation step.

Kind regards,

William

On Sat, May 9, 2015 at 4:44 PM, daniela florescu <dflorescu at me.com> wrote:
> Adam,
>
> sorry, will not respond this thread from now on. It?s a waste of my time.
>
> Best
> Dana
>
>
>
>
>> On May 9, 2015, at 4:42 PM, Adam Retter <adam.retter at googlemail.com> wrote:
>>
>>> Botton line is: as a result of what W3C did with XQuery 3.1, they created
>>> more harm them good overall for the industry.
>>>
>>>
>>> And this:  for both the XML community  AND  the JSON community.
>>>
>>> For the XML community: they?ll be hated and avoided even more they used to
>>> be, and more and more isolated, and
>>
>> I don't understand your perspective at all.
>> I don't believe that XQuery is perfect, but then I don't believe that
>> any other programming or query language is either. Significantly
>> however we do have real XQuery 3.1 users (that were previously using
>> XQuery 3.0 and XQuery 1.0) publicly thanking us for the new features
>> of XQuery 3.1 that they are enjoying, here is one such recent thank
>> you - http://exist.markmail.org/thread/mb7jdspx5h3d67kj
>>
>>
>>> For the JSON community:  they?ll avoid anything related to XQuery like scary
>>> evil, which means that they?ll design silly query languages
>>> by themselves (see Cassandra, see Mongo, see BigTable?.)  for 15 years
>>> before finding some decent solution.
>>
>> JSON is important sure, but I don't believe it is the beginning and
>> the end of the Web and/or NoSQL. You mention Cassandra, but their
>> query language CQL appears to me to be inspired by SQL rather than
>> anything like JSONiq.
>>
>> I really like JSONiq, I even started an implementation (unfinished) a
>> few years back. However, I have no sympathy for people or communities
>> that want to ignore a technology base because it is `scary evil`, I
>> don't buy into that as an argument, it just sounds like FUD; Serious
>> implementers of any language will always do their homework and learn
>> about the best and worst of their predecessors.
>>
>> Regards Mongo, the only JSONiq implementation for that seems to be
>> from 28msec which you were heavily involved in I believe. Outside of
>> 28msec and their partner work (IBM), apart from Xidel, I have not seen
>> any implementations of JSONiq. Certainly the NoSQL databases that you
>> mention, don't require a W3C stamped query language for them to
>> produce an implementation. I would be genuinely interested to know why
>> JSONiq was not more widely adopted? I really believed that JSONiq
>> would be snapped up very quickly by NoSQL JSON/BSON stores, Node.js
>> and others.
>>
>> I think that if people want just a JavaScript query language for JSON
>> then why don't they just get/create an implementation of JSONiq in
>> JavaScript? Sure it could have been XQuery 3.1, but it's not... and
>> well... I think that is okay. XQuery 3.1 has its own use-cases and
>> purpose, it might not be as popular as JSON, but I don't see that as
>> an issue, they solve different (and sometimes similar) problems.
>>
>>
>>
>> --
>> Adam Retter
>>
>> skype: adam.retter
>> tweet: adamretter
>> http://www.adamretter.org.uk
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From adam.retter at googlemail.com  Sun May 10 01:27:02 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Sun, 10 May 2015 09:27:02 +0100
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <CAM7ytN9Bz0y20DhYjf+oq91fd2dhoEqa8EaQUU8xALf7wmYwaA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
	<4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
	<CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>
	<83FE05C5-2C9C-4474-BC81-DEF8560BF41B@me.com>
	<CAM7ytN9Bz0y20DhYjf+oq91fd2dhoEqa8EaQUU8xALf7wmYwaA@mail.gmail.com>
Message-ID: <CAPK0iciwbn42s_7Zp2AhCTctL8__0qjp4CCknLY6zrX2y+QiSQ@mail.gmail.com>

> To answer your last question, there is a typescript implementation of
> JSONiq that started here: https://github.com/wcandillon/jsoniq.
> It will be interesting to see the reception in the NoSQL and HTML5
> community when this project will be a bit more mature.
>
> It implements JSONiq updates and update composition on top of
> IndexedDB. The end goal is to query/update IndexedDB and implement a
> versioning system between IndexedDB and the cloud. Compiled queries
> can run as standalone JavaScript programs: it's very lightweight.
> It is tested against both browsers and nodejs.

That's awesome and exactly the sort of good fit for JSONiq that I
expected to be adopted by the JavaScript community.

I wondered in terms of JSONiq support whether it is possible to do
without IndexedDB, i.e. just be able to query JSON files and/or JSON
coming in over the http (via AJAX and WebSockets etc)?

Out of interest, regards Node.js, what do you use for the IndexedDB?

> This implementation is 100% organically grown.  We started with an
> XQuery parser in JavaScript for HTML5 editors. We then added static
> analysis for errors and warnings (XQLint). XQLint is quite mature now
> and the next logical step was to add a code generation step.

I wish you all the best with this project. I hope it gets the
attention it deserves from the JavaScript community. I will be
interested to see how it goes...



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

From wcandillon at gmail.com  Sun May 10 01:39:44 2015
From: wcandillon at gmail.com (William Candillon)
Date: Sun, 10 May 2015 01:39:44 -0700
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <CAPK0iciwbn42s_7Zp2AhCTctL8__0qjp4CCknLY6zrX2y+QiSQ@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
	<4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
	<CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>
	<83FE05C5-2C9C-4474-BC81-DEF8560BF41B@me.com>
	<CAM7ytN9Bz0y20DhYjf+oq91fd2dhoEqa8EaQUU8xALf7wmYwaA@mail.gmail.com>
	<CAPK0iciwbn42s_7Zp2AhCTctL8__0qjp4CCknLY6zrX2y+QiSQ@mail.gmail.com>
Message-ID: <CAM7ytN9EW711N+wimwkMpnx5dnr9TVowokd2zAiJDHhzprBv3w@mail.gmail.com>

On Sun, May 10, 2015 at 1:27 AM, Adam Retter <adam.retter at googlemail.com> wrote:
>> To answer your last question, there is a typescript implementation of
>> JSONiq that started here: https://github.com/wcandillon/jsoniq.
>> It will be interesting to see the reception in the NoSQL and HTML5
>> community when this project will be a bit more mature.
>>
>> It implements JSONiq updates and update composition on top of
>> IndexedDB. The end goal is to query/update IndexedDB and implement a
>> versioning system between IndexedDB and the cloud. Compiled queries
>> can run as standalone JavaScript programs: it's very lightweight.
>> It is tested against both browsers and nodejs.
>
> That's awesome and exactly the sort of good fit for JSONiq that I
> expected to be adopted by the JavaScript community.
>
> I wondered in terms of JSONiq support whether it is possible to do
> without IndexedDB, i.e. just be able to query JSON files and/or JSON
> coming in over the http (via AJAX and WebSockets etc)?
The architecture is completely decoupled from IndexedDB.
Querying/Updating IndexedDB is simply the closest use case for us.

>
> Out of interest, regards Node.js, what do you use for the IndexedDB?
>
>> This implementation is 100% organically grown.  We started with an
>> XQuery parser in JavaScript for HTML5 editors. We then added static
>> analysis for errors and warnings (XQLint). XQLint is quite mature now
>> and the next logical step was to add a code generation step.
>
> I wish you all the best with this project. I hope it gets the
> attention it deserves from the JavaScript community. I will be
> interested to see how it goes...
Thanks Adam!

>
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk

From adam.retter at googlemail.com  Sun May 10 02:37:44 2015
From: adam.retter at googlemail.com (Adam Retter)
Date: Sun, 10 May 2015 10:37:44 +0100
Subject: [xquery-talk] [xml-dev] Query 3.1 vs. JSONiq WAS Re: MarkLogic
 using JSONiq for processing JSON ?
In-Reply-To: <CAM7ytN9EW711N+wimwkMpnx5dnr9TVowokd2zAiJDHhzprBv3w@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<B512C2F1-E975-49BA-89E2-7DE37D6EB02F@saxonica.com>
	<CC955172-DC4C-462C-9E6D-23725D75DABB@me.com>
	<05382C8A-D99B-4178-9663-D1E78D650F1E@saxonica.com>
	<4BB82FCF-F60B-42B2-B626-8C7FD0104C5F@me.com>
	<CAPK0iciH4PRRKg3K=y_R-smay1U9iVm8p3EmMu1U0j8q=_XCYQ@mail.gmail.com>
	<83FE05C5-2C9C-4474-BC81-DEF8560BF41B@me.com>
	<CAM7ytN9Bz0y20DhYjf+oq91fd2dhoEqa8EaQUU8xALf7wmYwaA@mail.gmail.com>
	<CAPK0iciwbn42s_7Zp2AhCTctL8__0qjp4CCknLY6zrX2y+QiSQ@mail.gmail.com>
	<CAM7ytN9EW711N+wimwkMpnx5dnr9TVowokd2zAiJDHhzprBv3w@mail.gmail.com>
Message-ID: <CAPK0ichbB+fXh2pnrBAQjyVVxREt3Ae87U5=0worjq46KKK7iw@mail.gmail.com>

>> I wondered in terms of JSONiq support whether it is possible to do
>> without IndexedDB, i.e. just be able to query JSON files and/or JSON
>> coming in over the http (via AJAX and WebSockets etc)?
> The architecture is completely decoupled from IndexedDB.
> Querying/Updating IndexedDB is simply the closest use case for us.
>

Nice. Hopefully in a few months when things let up a bit I will have
some time to take it for a spin.

-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

From dflorescu at me.com  Mon May 11 17:56:55 2015
From: dflorescu at me.com (daniela florescu)
Date: Mon, 11 May 2015 17:56:55 -0700
Subject: [xquery-talk] my answer to my "MarkLogic's support for JSON"
	question
Message-ID: <DC2C7A1D-39DA-445D-BFB2-996C718E3FFE@me.com>

After a little bit of Googling, it seems that the answer to my question is much sillier then I originally thought.

MarkLogic queries/processes JSON (potentially TB or more of JSON data)? through?.well... Javascript.

Well, as a ?data scientist? (hey, everyone else is one, why not me :-), I am speechless.

I knew that companies with good marketing and expensive sales who play golf can sell all kinds of BS to their customers.

But still, that?s talking your database customers for total idiots.

===============================

Dear MarkLogic people, dear Gary Bloom (CEO of MarkLogic), did I understand correctly that Javascript is your answer  !!!????

===============================

If I didn?t get it wrong, and that?s what you currently do, you obviously NEED to do something else.


And I can see only three possible choices for you:

1. You use XQuery 3.1. as it is designed by an esteemed and very nice W3C committee.
 Seems like a bad choice, as the JSON-only people will hate it ? see the previous discussion, but not as bad as Javascript.

2. You ?make up? your own JSON query language.  
Good luck with that. Sounds an even worse choice then the previous one.

3. You use JSONiq. 
That you would be smart and without any problems (JSONiq is an open specification, so by all means, please do), but in this case, 
please be intellectually honest and admit it publicly.



Best regards, (and oh, apologizes in advance to the MarkLogic's lawyers who must pull their hairs out 
trying to figure out how to answer my emails ? sorry !)


Dana


P.S. MarkLogic, when you take yourself so seriously as to ?We are the leaders in the NoSQL  world..?, blah, blah, please remember the saying
?with great authority come great responsibility?. At least the responsibility to be intelligent in technical choices.

From dflorescu at me.com  Wed May 13 01:04:48 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 13 May 2015 01:04:48 -0700
Subject: [xquery-talk] my answer to my "MarkLogic's support for JSON"
	question
In-Reply-To: <DC2C7A1D-39DA-445D-BFB2-996C718E3FFE@me.com>
References: <DC2C7A1D-39DA-445D-BFB2-996C718E3FFE@me.com>
Message-ID: <07EBA7DE-C167-47D6-A3E9-2D0DABB82079@me.com>

Recent linkedin discussion.

Not sure why Andrei thought that this concerns me :-)))

It doesn?t. I really don?t care.

No matter how many bizzilions/gazzilions of $$$ MarkLogic is evaluated to, they still have ZERO innovation,
 their technology is mediocre, and they have no long term vision.

Do I hear someone saying: "here comes Oracle again? !?:-)
(without Larry Ellison though..)

Best regards
Dana


Daniela Florescu <https://www.linkedin.com/profile/view?id=910384&authType=name&authToken=IP5T&trk=hp-feed-member-name> commented on this
 <https://www.linkedin.com/profile/view?id=10097757&authType=name&authToken=6zdS&trk=hp-feed-member-photo>
Andrei Yigal Lopatenko <https://www.linkedin.com/profile/view?id=10097757&authType=name&authToken=6zdS&trk=hp-feed-member-name>
Head of Search Quality @ WalmartLabs <https://www.linkedin.com/profile/view?id=10097757&authType=name&authToken=6zdS&trk=hp-feed-member-name>
Daniela Florescu <https://www.linkedin.com/profile/view?id=910384&authType=name&authToken=IP5T&trk=hp-feed-member-name> time of database companies https://lnkd.in/b8j4Tvv <https://lnkd.in/b8j4Tvv>
 <http://blogs.wsj.com/venturecapital/2015/05/12/database-vendor-marklogic-joins-billion-dollar-club-with-new-funding/>
Database Vendor MarkLogic Joins Billion-Dollar Club With New Funding
blogs.wsj.comMarkLogic Corp. has joined the ranks of the world?s most valuable private companies, raising $102 million ?
 <http://blogs.wsj.com/venturecapital/2015/05/12/database-vendor-marklogic-joins-billion-dollar-club-with-new-funding/>LikeCommentShare22 people like this.33 comments.
 <https://www.linkedin.com/profile/view?id=910384&authType=name&authToken=IP5T&trk=hp-feed-commenter-photo>16hDaniela Florescu <https://www.linkedin.com/profile/view?id=910384&authType=name&authToken=IP5T&trk=hp-feed-commenter-name>And why is this for me, Andrei !???Delete
 <https://www.linkedin.com/profile/view?id=910384&authType=&authToken=&trk=>nowDaniela Florescu <https://www.linkedin.com/profile/view?id=910384&authType=&authToken=&trk=>MarkLogic has a mediocre implementation of a W3C standard which is NOT designed by them but by the W3C: XQuery. There is no single technical innovation that I can see from MarkLogic. They've been good at hiring expensive sales people who play good golf and fool lots of customers that the advantages they get are coming from MarkLogic itself ,... vs the underlying technology (XQuery) -- which is the real truth.
 <https://www.linkedin.com/profile/view?id=910384&authType=&authToken=&trk=>nowDaniela Florescu <https://www.linkedin.com/profile/view?id=910384&authType=&authToken=&trk=> The sad problem is: customers are technically uneducated and willing to listen to all kinds of sales/snake oil stories. Or maybe there are some other reasons why customers are willing to pay a fortune for something they can get for free.... but then, other then stupidity, the reason escapes me. But who am I to judge if someone REALLY wants to waste 300K per CPU for something they can get fore free... !? If there are government customers, and this is MY taxes money, well.... I MIGHT have a problem with that, naturally.
> On May 11, 2015, at 5:56 PM, daniela florescu <dflorescu at me.com> wrote:
> 
> After a little bit of Googling, it seems that the answer to my question is much sillier then I originally thought.
> 
> MarkLogic queries/processes JSON (potentially TB or more of JSON data)? through?.well... Javascript.
> 
> Well, as a ?data scientist? (hey, everyone else is one, why not me :-), I am speechless.
> 
> I knew that companies with good marketing and expensive sales who play golf can sell all kinds of BS to their customers.
> 
> But still, that?s talking your database customers for total idiots.
> 
> ===============================
> 
> Dear MarkLogic people, dear Gary Bloom (CEO of MarkLogic), did I understand correctly that Javascript is your answer  !!!????
> 
> ===============================
> 
> If I didn?t get it wrong, and that?s what you currently do, you obviously NEED to do something else.
> 
> 
> And I can see only three possible choices for you:
> 
> 1. You use XQuery 3.1. as it is designed by an esteemed and very nice W3C committee.
> Seems like a bad choice, as the JSON-only people will hate it ? see the previous discussion, but not as bad as Javascript.
> 
> 2. You ?make up? your own JSON query language.  
> Good luck with that. Sounds an even worse choice then the previous one.
> 
> 3. You use JSONiq. 
> That you would be smart and without any problems (JSONiq is an open specification, so by all means, please do), but in this case, 
> please be intellectually honest and admit it publicly.
> 
> 
> 
> Best regards, (and oh, apologizes in advance to the MarkLogic's lawyers who must pull their hairs out 
> trying to figure out how to answer my emails ? sorry !)
> 
> 
> Dana
> 
> 
> P.S. MarkLogic, when you take yourself so seriously as to ?We are the leaders in the NoSQL  world..?, blah, blah, please remember the saying
> ?with great authority come great responsibility?. At least the responsibility to be intelligent in technical choices.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150513/58e6e0f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0791889.jpg
Type: image/jpeg
Size: 4205 bytes
Desc: not available
URL: <http://x-query.com/pipermail/talk/attachments/20150513/58e6e0f8/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ext.jpeg
Type: image/jpeg
Size: 4601 bytes
Desc: not available
URL: <http://x-query.com/pipermail/talk/attachments/20150513/58e6e0f8/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00d31a4.jpg
Type: image/jpeg
Size: 2983 bytes
Desc: not available
URL: <http://x-query.com/pipermail/talk/attachments/20150513/58e6e0f8/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00d31a4.jpg
Type: image/jpeg
Size: 1059 bytes
Desc: not available
URL: <http://x-query.com/pipermail/talk/attachments/20150513/58e6e0f8/attachment-0002.jpg>

From ihe.onwuka at gmail.com  Wed May 13 01:35:51 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Wed, 13 May 2015 04:35:51 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
Message-ID: <CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>

On Sat, May 9, 2015 at 5:25 PM, daniela florescu <dflorescu at me.com> wrote:

> >>
> >
> > You can be assured that we had lively debates on this topic,
>
> After ?living? in the XQuery W3C working group for 15 years?.. I don?t
> doubt you had. I am just happy I was not there.
>
> But, sorry, W3C took the wrong decision: in one instant with this
> decision, you lost the JSON community.
>
>
Is this not a variant of the Worse is Better argument (or did I not
properly understand that essay...... probably).

The issue with many JSON people is that they don't seem to acknowledge the
need for interoperability with XML so the utility of a "bilingual language"
probably doesn't resonate.

Without wishing to appear informed can I ask a question.

Was the Crockfordesque faction represented in the composition of the WG or
was it (of necessity) a bunch of XML people talking about how to support
JSON?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150513/6dcff35d/attachment.html>

From dflorescu at me.com  Wed May 13 01:55:43 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 13 May 2015 01:55:43 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
Message-ID: <73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>

> 
> The issue with many JSON people is that they don't seem to acknowledge the need for interoperability with XML so the utility of a "bilingual language" probably doesn't resonate. 


Ihe,

this is where the JSONiq authors (me included) we did spent a HUGE amount of energy for design:  in the following compromise:

(1) try to find a superset of XQuery 3.0 (so still stay in the XML world),  which can handle BOTH XML and JSON. 
This resulting language was not always pretty to look at, as you can imagine, because it inherited the syntactic
quirks of BOTH XML and JSON, yet it is very powerful and useful, as you can imagine, if in an application you need to mix and match both.

but in the same time, this billingual (expressive-power rich, but not pretty to look at, and not simple) language:

(b) was able to be syntactically subsetted to a VERY SIMPLE language for querying/processing JSON-only. This subset was maintaining the ?good? parts of XQuery 
(composability, declarativity, functional nature, optimizability, expressive power), while being aesthetically pleasing to a JSON-only crowd .


So I don?t agree with you. With JSONiq, we did prove that it IS possible to serve BOTh community with one underlying ?virtual machine?, if you want, and several syntaxes,
according to the ?beauty is in the eye of the beholder? principle.


> 
> Without wishing to appear informed can I ask a question.
> 
> Was the Crockfordesque faction represented in the composition of the WG or was it (of necessity) a bunch of XML people talking about how to support JSON?


I wasn?t there, so I cannot tell for sure.

But, after spending 16 years in the W3C, I  guess that , as usual, the crowd was dominated by XML people who pay little attention to where the world goes,
 outside their little XML  narrow interest.


That?s what I witnessed during my 16 years tenure within W3C XQuery Working Group.

And it wasn?t either productive, not funny.


Best regards
Dana





From ihe.onwuka at gmail.com  Wed May 13 02:11:40 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Wed, 13 May 2015 05:11:40 -0400
Subject: [xquery-talk] Fwd: [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
Message-ID: <CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>

---------- Forwarded message ----------
From: Ihe Onwuka <ihe.onwuka at gmail.com>
Date: Wed, May 13, 2015 at 5:11 AM
Subject: Re: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
3.1
To: daniela florescu <dflorescu at me.com>




On Wed, May 13, 2015 at 4:55 AM, daniela florescu <dflorescu at me.com> wrote:

> >
> > The issue with many JSON people is that they don't seem to acknowledge
> the need for interoperability with XML so the utility of a "bilingual
> language" probably doesn't resonate.
>
>
> Ihe,
>
> this is where the JSONiq authors (me included) we did spent a HUGE amount
> of energy for design:  in the following compromise:
>
> (1) try to find a superset of XQuery 3.0 (so still stay in the XML
> world),  which can handle BOTH XML and JSON.
> This resulting language was not always pretty to look at, as you can
> imagine, because it inherited the syntactic
> quirks of BOTH XML and JSON, yet it is very powerful and useful, as you
> can imagine, if in an application you need to mix and match both.
>
> but in the same time, this billingual (expressive-power rich, but not
> pretty to look at, and not simple) language:
>
> (b) was able to be syntactically subsetted to a VERY SIMPLE language for
> querying/processing JSON-only. This subset was maintaining the ?good? parts
> of XQuery
> (composability, declarativity, functional nature, optimizability,
> expressive power), while being aesthetically pleasing to a JSON-only crowd .
>
>
>
Sounds like Worse is Better.



> So I don?t agree with you. With JSONiq, we did prove that it IS possible
> to serve BOTh community with one underlying ?virtual machine?, if you want,
> and several syntaxes,
> according to the ?beauty is in the eye of the beholder? principle.
>
>
You misread me. Though not an expert but I have written some  JSONiq so I
can appreciate what you are saying.

 When i say JSON people I mean people like Marc (from the linkedin
discussion you started) and some others I have worked with who believe all
the myths  and think everything can and should be done in JSON. OK maybe
not that far out because such a person would never come to an XQuery WG but
you know the sort of people I mean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150513/caeb8ab8/attachment.html>

From dflorescu at me.com  Wed May 13 02:31:56 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 13 May 2015 02:31:56 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of
	XQuery	3.1
In-Reply-To: <CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
Message-ID: <9193A25D-08C7-4D60-B945-D440077D91C3@me.com>

> 
> You misread me. Though not an expert but I have written some  JSONiq so I can appreciate what you are saying.
> 
>  When i say JSON people I mean people like Marc (from the linkedin discussion you started) and some others I have worked with who believe all the myths  and think everything can and should be done in JSON. OK maybe not that far out because such a person would never come to an XQuery WG but you know the sort of people I mean.
>  


Yes, there are plenty of people in the world who consider XML and everything related to it (including XQuery) evil?..and JSON is all they want to see.


There are PLENTY of those.

As you say, in order to ?educate? those guys about how to avoid the traps of building a silly query language of their own for JSON/semi-structured data
  (because querying semi-strcuturded data is NOT trivial and   COMPLETELY different from querying flat, regular, relational data, so, no, SQL is NOT an answer?),
 you need to be a  little ? ?diplomat?? and understand THEIR needs, and talk THEIR language.

Stuff that the esteemed XQuery 3.1 WG had no clue how to do. I guess they didn?t care either.

Otherwise you end up with those hacks that are all the JSON query languages designed by Cassandra, MongoDb, etc, etc. 

No expressive power, and, worse, no clean semantics. (?let?s run it, and see what this query means??... kind of semantics..)

=============

Hence the subset of JSONiq, which is based on the rich expressive power of XQuery and has the clean semantics of XQuery, yet syntactically 
had absolutely NO mentioning of angle brackets AT ALL.

Just pure, pure JSON.

We did a mistake though, and forgot to rename ?for" into ?from? and ?return? into ?select? though ?


I am shocked when I hear people telling me that they don?t understand the semantics of

for $x in collection(?blah?)
return $x.a

but it is obviously clear to them the semantics of the following expression

from $x in collection(?blah?)
select $x.a


===========


What can I say !? We learned that habits are extremely strong for some people, and keywords hold a powerful meaning?.


Best regards
Dana

From benito at benibela.de  Wed May 13 05:05:40 2015
From: benito at benibela.de (Benito van der Zander)
Date: Wed, 13 May 2015 14:05:40 +0200
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
 3.1
In-Reply-To: <9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
Message-ID: <55533E14.3070603@benibela.de>


Hi,

> As you say, in order to ?educate? those guys about how to avoid the traps of building a silly query language of their own for JSON/semi-structured data
>    (because querying semi-strcuturded data is NOT trivial and   COMPLETELY different from querying flat, regular, relational data, so, no, SQL is NOT an answer?),
>   you need to be a  little ? ?diplomat?? and understand THEIR needs, and talk THEIR language.

Still JSONiq screwed up, when they did not think of an equivalent for 
$element/(child1, child2)/foo

At least $object . ("child1", "child2") . foo should have been allowed

> We did a mistake though, and forgot to rename ?for" into ?from? and ?return? into ?select? though ?

And the XQuery WG made a mistake, when they did not added macros.

#define from for
#define select return

I like C


Best,
Benito


On 13.05.2015 11:31, daniela florescu wrote:
>> You misread me. Though not an expert but I have written some  JSONiq so I can appreciate what you are saying.
>>
>>   When i say JSON people I mean people like Marc (from the linkedin discussion you started) and some others I have worked with who believe all the myths  and think everything can and should be done in JSON. OK maybe not that far out because such a person would never come to an XQuery WG but you know the sort of people I mean.
>>   
>
> Yes, there are plenty of people in the world who consider XML and everything related to it (including XQuery) evil?..and JSON is all they want to see.
>
>
> There are PLENTY of those.
>
> As you say, in order to ?educate? those guys about how to avoid the traps of building a silly query language of their own for JSON/semi-structured data
>    (because querying semi-strcuturded data is NOT trivial and   COMPLETELY different from querying flat, regular, relational data, so, no, SQL is NOT an answer?),
>   you need to be a  little ? ?diplomat?? and understand THEIR needs, and talk THEIR language.
>
> Stuff that the esteemed XQuery 3.1 WG had no clue how to do. I guess they didn?t care either.
>
> Otherwise you end up with those hacks that are all the JSON query languages designed by Cassandra, MongoDb, etc, etc.
>
> No expressive power, and, worse, no clean semantics. (?let?s run it, and see what this query means??... kind of semantics..)
>
> =============
>
> Hence the subset of JSONiq, which is based on the rich expressive power of XQuery and has the clean semantics of XQuery, yet syntactically
> had absolutely NO mentioning of angle brackets AT ALL.
>
> Just pure, pure JSON.
>
> We did a mistake though, and forgot to rename ?for" into ?from? and ?return? into ?select? though ?
>
>
> I am shocked when I hear people telling me that they don?t understand the semantics of
>
> for $x in collection(?blah?)
> return $x.a
>
> but it is obviously clear to them the semantics of the following expression
>
> from $x in collection(?blah?)
> select $x.a
>
>
> ===========
>
>
> What can I say !? We learned that habits are extremely strong for some people, and keywords hold a powerful meaning?.
>
>
> Best regards
> Dana
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From dflorescu at me.com  Wed May 13 10:38:12 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 13 May 2015 10:38:12 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <55533E14.3070603@benibela.de>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
Message-ID: <E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>

> 
> And the XQuery WG made a mistake, when they did not added macros.
> 
> #define from for
> #define select return
> 
> I like C
> 


The unfortunate choice of those two keywords (?for? and ?return? instead of ?from? and ?select?) in XQuery had 
such a HUGE impact on adoption (or not)  of  XQuery, it?s amazing.

It?s not too late to add the macros?..and make XQuery understandable to people who only want to see

select? from ...

Best regards
Dana




From joewiz at gmail.com  Wed May 13 12:03:56 2015
From: joewiz at gmail.com (Joe Wicentowski)
Date: Wed, 13 May 2015 15:03:56 -0400
Subject: [xquery-talk] @XQuery, #xquerypower, and related efforts
Message-ID: <CAHwerk0n9eFNY-YCsWSBBV1BoLpbMv=mLfDNjoCcRPhvvvyk6Q@mail.gmail.com>

Dear XQuery Talk,

Friends of Jim Fuller may know that, after many years of excellent
stewardship, Jim decided to give up his @xquery twitter account for
@_jim_fuller.  I've taken on the task of using the account to post links of
interest to users and learners of XQuery, and promoting the use of XQuery.

  https://twitter.com/XQuery

I'm currently posting a daily link to sites that are powered by XQuery.
I've begun collecting these in a simple GitHub page.  I would welcome all
to submit pull requests.

  https://github.com/joewiz/xquerypower

And I'd encourage anyone interested to follow @XQuery.  I'll gladly retweet
items of interest, and the easiest way for me to notice you is to use the
term "XQuery"!

Thanks,
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150513/53f09015/attachment.html>

From joewiz at gmail.com  Wed May 13 12:06:33 2015
From: joewiz at gmail.com (Joe Wicentowski)
Date: Wed, 13 May 2015 15:06:33 -0400
Subject: [xquery-talk] @XQuery, #xquerypower, and related efforts
In-Reply-To: <CAHwerk0n9eFNY-YCsWSBBV1BoLpbMv=mLfDNjoCcRPhvvvyk6Q@mail.gmail.com>
References: <CAHwerk0n9eFNY-YCsWSBBV1BoLpbMv=mLfDNjoCcRPhvvvyk6Q@mail.gmail.com>
Message-ID: <CAHwerk1CXsFn8xcyr3LUXM=H=a+S51mbpDGmHOgOhsMNmHn85A@mail.gmail.com>

Correction: Jim's new account is @_james_fuller.  Apologies, Jim!
https://twitter.com/_james_fuller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150513/6f3d44a7/attachment.html>

From ihe.onwuka at gmail.com  Sat May 16 09:59:10 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Sat, 16 May 2015 17:59:10 +0100
Subject: [xquery-talk] [xml-dev] Re: [xml-dev] Mistakes made in the
 design of XQuery 3.1
In-Reply-To: <5557685A.7090202@oracle.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<5557685A.7090202@oracle.com>
Message-ID: <CALfs7+zngkZaakGMJFtsFnSKTa3ZHvZS2wyX7M8mXxmApcZV_Q@mail.gmail.com>

On Sat, May 16, 2015 at 4:55 PM, Jim Melton <jim.melton at oracle.com> wrote:

>  In passing, I would like to observe that the title of the W3C Working
> Group being discussed is "XML Query Working Group" and the charter of that
> WG speaks of developing a query language for XML.  In fact, the language
> developed by the WG is called "XQuery: An XML Query Language".  While the
> WG, and its participants, understand the importance of JSON and have as a
> goal integration of support for querying XML data along with JSON data, the
> name and charter of the WG have not been changed to "JSON Query WG".
>
>
Might that be because JSON (for all intents and purposes) did not exist  at
the inception of the WG.

I mean it's not called the SQL Query WG either but the WG did have SQL as a
reference point because relational data formats were around and relevant at
the time.

So ......

That said I do empathise with both sides of this argument.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150516/e7ecefb5/attachment.html>

From dflorescu at me.com  Sat May 16 10:32:56 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 16 May 2015 10:32:56 -0700
Subject: [xquery-talk] [xml-dev] Re: [xml-dev] Mistakes made in the
 design of XQuery 3.1
In-Reply-To: <5557685A.7090202@oracle.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<5557685A.7090202@oracle.com>
Message-ID: <59680A83-6529-4C83-8FA9-D8058C91B6DF@me.com>


> On May 16, 2015, at 8:55 AM, Jim Melton <jim.melton at oracle.com> wrote:
> 
> In passing, I would like to observe that the title of the W3C Working Group being discussed is "XML Query Working Group" and the charter of that WG speaks of developing a query language for XML. 


Jim, 

please, this discussion starts to be repetitive and boring.

Stop running around the bush, too. Hypocrisy in technology is no good if you want to build useful; technology.

Simple hypocritical statement: ? we were not interested in querying JSON?. Huh. Yet you added JSON structures to it. 

Why not Protocol Buffer ? Why Not SQL relations ? Why not CSV ? Why not Scala structures ? The world is full of useful ?stuff??.

Why adding JSON, if you were explicitly not interested by it !?

But obviously, I don?t expect an answer to this question. The answer is obvious. You think people can be so easily fooled!?


> JSONiq is a very good technology developed specifically to integrate thorough JSON support alongside the XML Query facilities in XQuery. 

You bet it is. I don?t design shitty technology, and a lot of thought (not only mine, obviously, but a whole excellent team) went into that design.
[[ In fact, many good things in XQuery come from me: the functional aspect of XQuery, the FLWOR expression, the element constructor with dynamic content, 
the functions, the windowing, the composability of updates, etc, etc.]]

And, as a side, if you personally wouldn?t have told me ? We don?t need to hear your opinion? in a the middle of a W3C meeting, and you wouldn?t have allowed 
Sharon Adler to kick me out of a W3C meeting by cutting my phone line (both illegal behaviors by the standards of W3C, but Liam didn?t seem to ?notice"), 
today XQuery would have had a very nicely designed Scripting Extension  - similar to Stored Procedures in SQL, which would have enhanced the expressive
 power of XQuery dramatically.


Like Zorba used to have, before Zorba team was killed, with your personal help, Jim.

So, you know, Jim, please stop the hypocrisy and the wooden language here. I think it?s better for everyone.

I honestly don?t care, except that I feel sorry that all the (hardly acquired!) experience of XQuery is lost on the JSON guys, and they?ll see another 15 years of tribulations,
and billions of dollars wasted on the industry.

Hasta la Vista,
Dana



> However, as Mike Kay has stated several times, the goals of the XML Query WG were not identical to the goals of the group who designed JSONiq. Thus, given the primary focus of the XML Query WG and the goals of its participants, it is not surprising that the results of the WG's work differs from what the JSONiq developers might have hoped. 
> 
> Hope this helps,
>    One of the morons 
> 
> On 5/13/2015 2:35 AM, Ihe Onwuka wrote:
>> 
>> 
>> On Sat, May 9, 2015 at 5:25 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> >>
>> >
>> > You can be assured that we had lively debates on this topic,
>> 
>> After ?living? in the XQuery W3C working group for 15 years?.. I don?t doubt you had. I am just happy I was not there.
>> 
>> But, sorry, W3C took the wrong decision: in one instant with this decision, you lost the JSON community.
>> 
>> 
>> Is this not a variant of the Worse is Better argument (or did I not properly understand that essay...... probably). 
>> 
>> The issue with many JSON people is that they don't seem to acknowledge the need for interoperability with XML so the utility of a "bilingual language" probably doesn't resonate. 
>> 
>> Without wishing to appear informed can I ask a question.
>> 
>> Was the Crockfordesque faction represented in the composition of the WG or was it (of necessity) a bunch of XML people talking about how to support JSON?
>> 
> 
> -- 
> ========================================================================
> Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
>   Chair, ISO/IEC JTC1/SC32 and W3C XML Query WG    Fax : +1.801.942.3345
> Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
> 1930 Viscounti Drive      Alternate email: jim dot melton at acm dot org
> Sandy, UT 84093-1063 USA  Personal email: SheltieJim at xmission dot com
> ========================================================================
> =  Facts are facts.   But any opinions expressed are the opinions      =
> =  only of myself and may or may not reflect the opinions of anybody   =
> =  else with whom I may or may not have discussed the issues at hand.  =
> ======================================================================== 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150516/f13ffe70/attachment.html>

From benito at benibela.de  Mon May 18 08:23:41 2015
From: benito at benibela.de (Benito van der Zander)
Date: Mon, 18 May 2015 17:23:41 +0200
Subject: [xquery-talk] A doc()-map chain operator proposal
In-Reply-To: <59680A83-6529-4C83-8FA9-D8058C91B6DF@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>	<5557685A.7090202@oracle.com>
	<59680A83-6529-4C83-8FA9-D8058C91B6DF@me.com>
Message-ID: <555A03FD.6050407@benibela.de>


Hi,
if you query data from deep websites, you almost always end up with a 
long get-link-download chain like:

doc("http://example.org") // a [ condition 1 ] / doc( @href) //a [ 
condition 2 ] / doc(@href) //a [ condition 3 ] / doc(@href) / ....

Half the query is a / doc( @href) filler.
It is really ugly, isn't it?

How about replacing / doc( @href) with a single map operator? (or more 
general / doc((@href, at src, at action)[1])

Like ~

Looks much better:

doc("http://example.org") // a [ condition 1 ] ~ //a [ condition 2 ] ~ 
//a [ condition 3 ] ~ / ....

Or !!

doc("http://example.org") // a [ condition 1 ] !! //a [ condition 2 ] !! 
//a [ condition 3 ] !! / ....

Does it not?



What do you think?

I guess the WG is not going to add it soon? Are any other ~ or !! 
operators planed?
Because it would be a shame to add it in an implementation, and then get 
XQuery 4, where there is a ~ operator that does something completely 
different.

Best,
Benito


From mike at saxonica.com  Mon May 18 08:36:12 2015
From: mike at saxonica.com (Michael Kay)
Date: Mon, 18 May 2015 16:36:12 +0100
Subject: [xquery-talk] A doc()-map chain operator proposal
In-Reply-To: <555A03FD.6050407@benibela.de>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<5557685A.7090202@oracle.com>
	<59680A83-6529-4C83-8FA9-D8058C91B6DF@me.com>
	<555A03FD.6050407@benibela.de>
Message-ID: <1F4E331F-F832-469A-B18F-3BDD5E016586@saxonica.com>

I think it would be quite inappropriate for any function or operator in XPath to attach special meaning to attribute of a particular name, such as @href. The only way it would make sense would be is if there?s a W3C defining the semantics of the attribute - e.g. @xlink:href - but almost no-one uses that. 

> 
> Because it would be a shame to add it in an implementation, and then get XQuery 4, where there is a ~ operator that does something completely different.
> 

Indeed, that is why XQuery does not allow a conformant implementation to add its own operators.

Michael Kay
Saxonica



From benito at benibela.de  Mon May 18 08:56:12 2015
From: benito at benibela.de (Benito van der Zander)
Date: Mon, 18 May 2015 17:56:12 +0200
Subject: [xquery-talk] A doc()-map chain operator proposal
In-Reply-To: <1F4E331F-F832-469A-B18F-3BDD5E016586@saxonica.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>	<5557685A.7090202@oracle.com>	<59680A83-6529-4C83-8FA9-D8058C91B6DF@me.com>	<555A03FD.6050407@benibela.de>
	<1F4E331F-F832-469A-B18F-3BDD5E016586@saxonica.com>
Message-ID: <555A0B9C.2000305@benibela.de>


Hi Michael,

> I think it would be quite inappropriate for any function or operator in XPath to attach special meaning to attribute of a particular name, such as @href. The only way it would make sense would be is if there?s a W3C defining the semantics of the attribute - e.g. @xlink:href - but almost no-one uses that.

Well, HTML defines its own semantics for all elements and attributes.

> Indeed, that is why XQuery does not allow a conformant implementation to add its own operators.

Too late to care about that, when there are already JSONiq's constructors.


Cheers,
Benito


On 18.05.2015 17:36, Michael Kay wrote:
> I think it would be quite inappropriate for any function or operator in XPath to attach special meaning to attribute of a particular name, such as @href. The only way it would make sense would be is if there?s a W3C defining the semantics of the attribute - e.g. @xlink:href - but almost no-one uses that.
>
>> Because it would be a shame to add it in an implementation, and then get XQuery 4, where there is a ~ operator that does something completely different.
>>
> Indeed, that is why XQuery does not allow a conformant implementation to add its own operators.
>
> Michael Kay
> Saxonica
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From mike at saxonica.com  Mon May 18 09:04:44 2015
From: mike at saxonica.com (Michael Kay)
Date: Mon, 18 May 2015 17:04:44 +0100
Subject: [xquery-talk] A doc()-map chain operator proposal
In-Reply-To: <555A0B9C.2000305@benibela.de>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<5557685A.7090202@oracle.com>
	<59680A83-6529-4C83-8FA9-D8058C91B6DF@me.com>
	<555A03FD.6050407@benibela.de>
	<1F4E331F-F832-469A-B18F-3BDD5E016586@saxonica.com>
	<555A0B9C.2000305@benibela.de>
Message-ID: <8DEA67FB-5607-405D-965F-A3C0658D1DBD@saxonica.com>


> On 18 May 2015, at 16:56, Benito van der Zander <benito at benibela.de> wrote:
> 
> 
> Hi Michael,
> 
>> I think it would be quite inappropriate for any function or operator in XPath to attach special meaning to attribute of a particular name, such as @href. The only way it would make sense would be is if there?s a W3C defining the semantics of the attribute - e.g. @xlink:href - but almost no-one uses that.
> 
> Well, HTML defines its own semantics for all elements and attributes.

Yes, and that would be a possible way forward; though we?ve avoided providing XPath functions and operators that are specialized to a particular vocabulary in the past.
> 
>> Indeed, that is why XQuery does not allow a conformant implementation to add its own operators.
> 
> Too late to care about that, when there are already JSONiq's constructors.
> 

You can of course write implementations of languages that have the XQuery grammar as a subset, but they are not conformant XQuery implementations. Whether people care is another matter...

Michael Kay
Saxonica

From ihe.onwuka at gmail.com  Wed May 20 01:35:57 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Wed, 20 May 2015 04:35:57 -0400
Subject: [xquery-talk] MarkLogic using JSONiq for processing JSON ?
In-Reply-To: <09E024AB-C01F-4498-A274-740A1D380723@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
	<09E024AB-C01F-4498-A274-740A1D380723@me.com>
Message-ID: <CALfs7+zYdMoXQs1yef5R-GPuPmcGdJ2V2kwB+dDaLF4tVm3n_w@mail.gmail.com>

On Sun, May 10, 2015 at 12:41 AM, daniela florescu <dflorescu at me.com> wrote:

>
> You both prove my point: the design of XQuery 3.1 was done to ?help?
> selfishly and with a very short term vision two-three companies (Saxon,
> Exist, MarkLogic), and with complete
> disregard to the big picture of the needs of querying and processing
> semi-structured data in the industry (which includes both XML and JSON).
>
>
Ok this is anecdotal and on a somewhat different tack but a couple of
months ago I took the Marklogic Developer course.  One of the few things I
retained from the course was the realisation that the instructor had no
idea what was in the XQuery specifiation (1.0 or 3.0) and in what way they
differed from the Marklogic variant.

Now that certainly makes me wonder whether that is reflective of the
corporate technical viewpoint.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150520/2b03b6f2/attachment.html>

From dflorescu at me.com  Wed May 20 11:27:20 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 20 May 2015 11:27:20 -0700
Subject: [xquery-talk] what XQuery COULD have done for the world...
Message-ID: <42C6487F-1BE1-4139-A49A-FCA7F5CC820C@me.com>

? if a bunch of standards people would have had some vision and some global understanding of technology:

They could have helped those NoSQL ?innocents? who will try for the next 15 years to use SQL for schema-free data,
and waste billions of dollars in the process, and slow down considerably the advancement of database technology.

See today (bellow) another one of those schema-free SQL languages.
https://www.linkedin.com/pulse/industrys-first-schema-free-sql-engine-apache-drill-paul-tarantino

I think I see at this point one of those ?SQL for NoSQL? every 2-3 days. Each equally pathetic. 

Including the ones from more serious NoSQL companies, like Cassandra (DataStax):
https://cassandra.apache.org/doc/cql/CQL.html

If you look at the semantics (or lackthereof ) of their ?SQL? language, and after 16 years of designing XQuery, it?s SAD?..

XQuery COULD have helped. 

But it didn?t.

Oh well, thanks again those without any long term vision in the XQuery WG ? but hey, they had POWER !

Dana






From dflorescu at me.com  Wed May 20 13:20:49 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 20 May 2015 13:20:49 -0700
Subject: [xquery-talk] [xml-dev] MarkLogic using JSONiq for processing
 JSON ?
In-Reply-To: <CALfs7+zYdMoXQs1yef5R-GPuPmcGdJ2V2kwB+dDaLF4tVm3n_w@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<CAPK0iciv5SUMvBam+9_t3u0He_y1b2TDwpBgSc=GZz7Qk=Pp4Q@mail.gmail.com>
	<09E024AB-C01F-4498-A274-740A1D380723@me.com>
	<CALfs7+zYdMoXQs1yef5R-GPuPmcGdJ2V2kwB+dDaLF4tVm3n_w@mail.gmail.com>
Message-ID: <4CC61C58-1A30-4813-A71A-D4CF77BFA2A3@me.com>

> 
> Ok this is anecdotal and on a somewhat different tack but a couple of months ago I took the Marklogic Developer course.  One of the few things I retained from the course was the realisation that the instructor had no idea what was in the XQuery specifiation (1.0 or 3.0) and in what way they differed from the Marklogic variant. 

Ihe,

what I find not only pathetic, but totally reprehensible, in MarkLogic?s way of conducting business is:

(1) they don?t tell their customers that all the technology they use is based on an industrial standard in which 
about 15 (years) times 20-30 (people = 3000-4500 man/year were invested by various companies : XQuery.

The advantages (flexibility, integration, blah, blah) that MarkLogic sells to its customers come mostly from the design of XQuery, not from anywhere else.

Yet, most customers never heard of XQuery. I talked to many of them. Users of XQuery for XXX years, yet they never heard of XQuery from 
MarkLogic?.

That?s very reprehensible business behavior: it?s called lack of scientific and intellectual irresponsibility.  And it?s done ON PURPOSE.

( Even worse, I think even their own salesforce has no clue about XQuery?..)


(2) just look at the www.marklogic.com <http://www.marklogic.com/>

The first who spots the word ?XQuery? somewhere, gets a special cookie from me :-)

I wasn?t able to find it?.

How would the users be able to figure that MarkLogic didn?t invent ANY that !? You take them wining, dining and golfing, and ? here you go.

(3) look at MarkLogic?s CEO, Gary Bloom, explaining to it?s customers about the ?beauty? of MarkLogic:

https://www.youtube.com/watch?v=EgBDSzak6jQ <https://www.youtube.com/watch?v=EgBDSzak6jQ>

Gary, no kidding man, you realized (finally!) that XQuery is used for data heterogeneous, schema-less data processing, for data integration and such?..!!!!!

WOW. I am impressed.

You finally got what the main design goal of XQuery WAS ?.. It?s only 20 years TOO late :-)

Sorry, Gary, the fact that you spent your life in Oracle doesn?t excuse your ignorance in managing heterogeneous data.

====================

Gary Bloom, when you say ?WE have a solution?   ?. you mean  ****** ?XQuery community has a solution?**********


Bring up some intellectual honesty, Gary, and stop bullshitting your customers.

Dana








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150520/c298b8ab/attachment.html>

From ihe.onwuka at gmail.com  Wed May 20 23:47:19 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 21 May 2015 02:47:19 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
Message-ID: <CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>

On Wed, May 13, 2015 at 1:38 PM, daniela florescu <dflorescu at me.com> wrote:

>
> The unfortunate choice of those two keywords (?for? and ?return? instead
> of ?from? and ?select?) in XQuery had
> such a HUGE impact on adoption (or not)  of  XQuery, it?s amazing.
>
> It?s not too late to add the macros?..and make XQuery understandable to
> people who only want to see
>
> select? from ...
>
>
Big mistakes.

Not co-opting a hardcore JSON zealot. I mean look at what they have
achieved with propaganda and myths and then imagine what could be possible
if you could convert a couple of them. Then again it could be like trying
to switch someone's sexual orientation (it's worth pondering why that
comparison is apt).

Bigger mistake

Not calling it JQuery.

 Nuff said.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150521/ffc774a1/attachment.html>

From ihe.onwuka at gmail.com  Thu May 21 00:17:53 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 21 May 2015 08:17:53 +0100
Subject: [xquery-talk] what XQuery COULD have done for the world...
In-Reply-To: <42C6487F-1BE1-4139-A49A-FCA7F5CC820C@me.com>
References: <42C6487F-1BE1-4139-A49A-FCA7F5CC820C@me.com>
Message-ID: <CALfs7+zkULuxh11VPp2JzRkes=VnjCC37xckJj0ayX3dH4yGFg@mail.gmail.com>

Look I don't want to try to appear smarter than I am so I caveat my
comments by saying that I'm not an expert but I get the thrust of what your
saying.

It's  a consequence of the general lack of programming language education
within the industry. Actually it's not just industry, universities graduate
computer science students without making them take a course in programming
languages - many don't even have one  on the curriculum.

So people learn to program without being equipped and are sometimes
elevated to the status of programming demi-god without ever having the
ability  to evaluate programming languages and while they will argue that
they can pick up other languages you can't pick up the ability to evaluate
them. You have to study that. Hence  we have a situation where the most
complicated programming paradigm - OOP is the most popular and is generally
but wrongly thought to be (relatively) simple and more capable.

People take what they (think they) know and feel comfortable with and
transplant it into a different setting without being equipped to give or
giving proper consideration to it's applicability in it's new environment.
SQL/NOSQL is not the first and won't be the last instance of this happening.


On Wed, May 20, 2015 at 7:27 PM, daniela florescu <dflorescu at me.com> wrote:

> ? if a bunch of standards people would have had some vision and some
> global understanding of technology:
>
> They could have helped those NoSQL ?innocents? who will try for the next
> 15 years to use SQL for schema-free data,
> and waste billions of dollars in the process, and slow down considerably
> the advancement of database technology.
>
> See today (bellow) another one of those schema-free SQL languages.
>
> https://www.linkedin.com/pulse/industrys-first-schema-free-sql-engine-apache-drill-paul-tarantino
>
> I think I see at this point one of those ?SQL for NoSQL? every 2-3 days.
> Each equally pathetic.
>
> Including the ones from more serious NoSQL companies, like Cassandra
> (DataStax):
> https://cassandra.apache.org/doc/cql/CQL.html
>
> If you look at the semantics (or lackthereof ) of their ?SQL? language,
> and after 16 years of designing XQuery, it?s SAD?..
>
> XQuery COULD have helped.
>
> But it didn?t.
>
> Oh well, thanks again those without any long term vision in the XQuery WG
> ? but hey, they had POWER !
>
> Dana
>
>
>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150521/4501c2fe/attachment.html>

From christian.gruen at gmail.com  Thu May 21 06:54:37 2015
From: christian.gruen at gmail.com (=?UTF-8?Q?Christian_Gr=C3=BCn?=)
Date: Thu, 21 May 2015 15:54:37 +0200
Subject: [xquery-talk] [ANN] BaseX 8.2: The Summer Edition
Message-ID: <CAP94bnMOY5KFGszjzc22POfSO8mAszaH718F-TtYi2BLg0Zmug@mail.gmail.com>

Dear all,

We invite you to check out Version 8.2, the Summer Edition, of BaseX,
our XML database system and XQuery 3.1 processor! You can expect the
following features:

 XQUERY
 - much faster sequence modification via finger trees
 - improved compliance with XQuery 3.1

 DBA
 - open, save and delete queries
 - better Tomcat support

 STORAGE
 - updatable index structures: reduced disk space consumption

 XQUERY FUNCTIONS
 - Standard Module: fn:json-to-xml, fn:xml-to-json
 - Web Module: web:encode-url, web:decode-url
 - File Module: file:is-absolute, file:resolve-path
 - Admin Module: admin:delete-logs
 - Database Module: db:output-cache

 BUG FIXES
 - locking, full-text requests, stemming

 REMOVED FEATURES
 - event handling (will be replaced by database triggers)

The latest version is available at http://basex.org. As usual, various
minor bugs and inconsistencies have been fixed in the latest version;
check out our documentation (http://docs.basex.org) and the GitHub
commits (https://github.com/BaseXdb/basex) for more details!

We are looking forward to your feedback,
Your BaseX Team

From dflorescu at me.com  Fri May 22 18:11:43 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 22 May 2015 18:11:43 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+xY8HbL0TEsEN-hoZoSJ9JAX7EaAyDQzeL=JihOzeprNA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+xY8HbL0TEsEN-hoZoSJ9JAX7EaAyDQzeL=JihOzeprNA@mail.gmail.com>
Message-ID: <2A95E189-E4B2-4706-8263-3A7BA1DB9A4F@me.com>

> 
> The unfortunate choice of those two keywords (?for? and ?return? instead of ?from? and ?select?) in XQuery had
> such a HUGE impact on adoption (or not)  of  XQuery, it?s amazing.
> 
> It?s not too late to add the macros?..and make XQuery understandable to people who only want to see
> 
> select? from ...
> 
> 
> Big mistakes.

Ihe, 

THAT particular choice of keywords (FOR/RETURN? instead of FROM/SELECT)?. is  MY mistake ENTIRELY. 100% MINE.

I regretted that (daily) in the past 16 years ?..and did LOTS of penance for it?..please believe me.

I could tell you the story? maybe it?s fun, maybe it?s interesting from a technology/history perspective.


=====

It was 1999, and I was a researcher in INRIA, studying query languages and query processing for semi-structured data. (since 1996 when I was in ATT Research)
I was stuck in Paris, where nothing ever happened in technology, and I was dreaming of going to Sillicon Valley, where EVERYTHING happened.
So, I managed to become a visiting scientist at IBM Almaden in Sillicon Valley.
My boss at that time, Mike Carey (now professor it Univ. Irvine), just decided to leave IBM for a startup ? Propel.
He didn?t know what to do with me (I was his responsibility :-) ?., so he took me by the hand to Don Chambelin (of SQL fame)
       across the hall, and he asked me: ?Why don?t  you work with Don Chamberlin on this XML query thing, after I am gone ??
That?s what I did, together with Jonathan Robie, and the result was Quilt, the precursor of XQuery.
Well, it happened that my PhD thesis was on query languages and query processing of object-oriented languages, and OQL was a functional language, above
and before being a query language. Hence, XQuery became a functional language.
Well, in the same time, I was teaching in a French university the ML programming language, a long love of mine, as programming languages are concerned.
Here is the catch: ML used the words FOR and RETURN for monoid comprehension?.which both the Select-From-Where of SQL and the FLOWR expression are.

Back to the story:

While in IBM, one evening Don Chamberlin asked me to write a grammar and a parser for Quilt. I spent the night doing that, and in the morning I showed him what I did.
As a fresh lover of ML, I used the keywords FOR and RETURN in the grammar.


Don looked at me and told me?. ?This thing?.we?ll call it a FLWOR expression.?


=======

</end-of-story>

It NEVER crossed my mind RIGHT THEN that that random decision that I took one night in a state of extreme fatigue will become cut-in-stone within
 the over-powerful standard that XQuery is today.


I guess lots of technical decisions happen this way?.randomly.


Best regards,
Dana


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150522/079b5806/attachment.html>

From dflorescu at me.com  Fri May 22 18:17:27 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 22 May 2015 18:17:27 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
Message-ID: <2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>

> 
> Bigger mistake
> 
> Not calling it JQuery.\

Ihe,

the second mistake you mention, not calling it JQuery.

I wish we could?. but JQuery was used for something else, alas:(

We didn?t have that choice?..:(

But I love the name JSONiq. It?s nice, and it?s cool, and more original then JQuery.

If I remember correctly, it was Jonathan Robie?s idea !

Dana


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150522/4c8f9e4e/attachment.html>

From ihe.onwuka at gmail.com  Mon May 25 01:29:10 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 25 May 2015 09:29:10 +0100
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
Message-ID: <CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>

No I meant not calling XQuery JQuery. I believe there was time for
that....... just imagine......

On Sat, May 23, 2015 at 2:17 AM, daniela florescu <dflorescu at me.com> wrote:

>
> Bigger mistake
>
> Not calling it JQuery.\
>
>
> Ihe,
>
> the second mistake you mention, not calling it JQuery.
>
> I wish we could?. but JQuery was used for something else, alas:(
>
> We didn?t have that choice?..:(
>
> But I love the name JSONiq. It?s nice, and it?s cool, and more original
> then JQuery.
>
> If I remember correctly, it was Jonathan Robie?s idea !
>
> Dana
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150525/c8a279ce/attachment.html>

From ihe.onwuka at gmail.com  Mon May 25 02:09:29 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 25 May 2015 10:09:29 +0100
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <2A95E189-E4B2-4706-8263-3A7BA1DB9A4F@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+xY8HbL0TEsEN-hoZoSJ9JAX7EaAyDQzeL=JihOzeprNA@mail.gmail.com>
	<2A95E189-E4B2-4706-8263-3A7BA1DB9A4F@me.com>
Message-ID: <CALfs7+yruMG+yDONnoL8RGWZ2dqVzvjAawaPFQd-yLoYtJ2qSw@mail.gmail.com>

On Sat, May 23, 2015 at 2:11 AM, daniela florescu <dflorescu at me.com> wrote:

>
>> The unfortunate choice of those two keywords (?for? and ?return? instead
>> of ?from? and ?select?) in XQuery had
>> such a HUGE impact on adoption (or not)  of  XQuery, it?s amazing.
>>
>> It?s not too late to add the macros?..and make XQuery understandable to
>> people who only want to see
>>
>> select? from ...
>>
>>
> Big mistakes.
>
>
> Ihe,
>
> THAT particular choice of keywords (FOR/RETURN? instead of FROM/SELECT)?.
> is  MY mistake ENTIRELY. 100% MINE.
>
> I regretted that (daily) in the past 16 years ?..and did LOTS of penance
> for it?..please believe me.
>
>
Methinks you are underestimating peoples hypocrisy.  Take something like

Select album from music_Artist where name = "The Police"

This is what passes without complaint in MQL a JSON based query language
(example from http://wiki.freebase.com/wiki/MQL)

{
  "type": "/music/artist",
  "name": "The Police",
  "album": []
}


If I may revert back to the SQL/NoSQL issue. People perceive SQL as just
that. A query language for querying  structured data and in their minds
that subsumes semi structured data. They don't see it as a codification of
relational algebra that operates on relations. If they did they might be
more hesitant about expecting anything good to result from applying SQL to
things that are not relations. That however, would require the learning of
a little bit of theory and unfortunately we have to co-exist with people
who write code for a living but passionately believe that being uneducated
is a virtue. These same people propagate blogs illustrated with simplistic
examples and before you know it Stupid Is As Stupid Does becomes the
defacto paradigm.

So don't beat yourself up about it.



> I could tell you the story? maybe it?s fun, maybe it?s interesting from a
> technology/history perspective.
>
>
> =====
>
> It was 1999, and I was a researcher in INRIA, studying query languages and
> query processing for semi-structured data. (since 1996 when I was in ATT
> Research)
> I was stuck in Paris, where nothing ever happened in technology, and I was
> dreaming of going to Sillicon Valley, where EVERYTHING happened.
> So, I managed to become a visiting scientist at IBM Almaden in Sillicon
> Valley.
> My boss at that time, Mike Carey (now professor it Univ. Irvine), just
> decided to leave IBM for a startup ? Propel.
> He didn?t know what to do with me (I was his responsibility :-) ?., so he
> took me by the hand to Don Chambelin (of SQL fame)
>        across the hall, and he asked me: ?Why don?t  you work with Don
> Chamberlin on this XML query thing, after I am gone ??
> That?s what I did, together with Jonathan Robie, and the result was Quilt,
> the precursor of XQuery.
> Well, it happened that my PhD thesis was on query languages and query
> processing of object-oriented languages, and OQL was a functional language,
> above
> and before being a query language. Hence, XQuery became a functional
> language.
> Well, in the same time, I was teaching in a French university the ML
> programming language, a long love of mine, as programming languages are
> concerned.
> Here is the catch: ML used the words FOR and RETURN for monoid
> comprehension?.which both the Select-From-Where of SQL and the FLOWR
> expression are.
>
>
Is that also where we got typeswitch from... ML?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150525/e031e52b/attachment.html>

From dflorescu at me.com  Tue May 26 16:09:08 2015
From: dflorescu at me.com (daniela florescu)
Date: Tue, 26 May 2015 16:09:08 -0700
Subject: [xquery-talk] test
Message-ID: <C1DE6A99-338E-493E-9BE4-FA27397DF1F8@me.com>


From dflorescu at me.com  Tue May 26 16:55:36 2015
From: dflorescu at me.com (daniela florescu)
Date: Tue, 26 May 2015 16:55:36 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+yruMG+yDONnoL8RGWZ2dqVzvjAawaPFQd-yLoYtJ2qSw@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+xY8HbL0TEsEN-hoZoSJ9JAX7EaAyDQzeL=JihOzeprNA@mail.gmail.com>
	<2A95E189-E4B2-4706-8263-3A7BA1DB9A4F@me.com>
	<CALfs7+yruMG+yDONnoL8RGWZ2dqVzvjAawaPFQd-yLoYtJ2qSw@mail.gmail.com>
Message-ID: <341792A8-4945-4493-A180-0E4FF777CE64@me.com>

> 
> 
> Is that also where we got typeswitch from... ML?

No, typeswitch was introduced to XQuery by Phil Wadler (of Haskell fame), and honestly, I was  personally against it when I first saw it.

(I remember the scene like it was yesterday? and Phil got really angry with me?and Adam Bosworth who was sitting next to me...) 

We could thank  Phil that he was persistent and ignored us ? :-)


Dana

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150526/e34a07c4/attachment.html>

From dflorescu at me.com  Wed May 27 22:19:13 2015
From: dflorescu at me.com (daniela florescu)
Date: Wed, 27 May 2015 22:19:13 -0700
Subject: [xquery-talk] message to the owners of this mailing list
Message-ID: <7904FD99-BE7E-400C-A279-9E78766BEFBB@me.com>


I get this now?..

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
talk-owner at x-query.com <mailto:talk-owner at x-query.com>.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150527/0e6fba73/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 83a25dea-bd3c-4f2e-974b-72efdaf48652-medium.jpeg
Type: image/jpeg
Size: 24030 bytes
Desc: not available
URL: <http://x-query.com/pipermail/talk/attachments/20150527/0e6fba73/attachment.jpeg>

From ihe.onwuka at gmail.com  Thu May 28 02:01:48 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 28 May 2015 10:01:48 +0100
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
Message-ID: <CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>

If XQuery had been called  JQuery people would have rushed to learn it
before they realised what it was. By which time it would have been too late.

On Mon, May 25, 2015 at 9:29 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

> No I meant not calling XQuery JQuery. I believe there was time for
> that....... just imagine......
>
> On Sat, May 23, 2015 at 2:17 AM, daniela florescu <dflorescu at me.com>
> wrote:
>
>>
>> Bigger mistake
>>
>> Not calling it JQuery.\
>>
>>
>> Ihe,
>>
>> the second mistake you mention, not calling it JQuery.
>>
>> I wish we could?. but JQuery was used for something else, alas:(
>>
>> We didn?t have that choice?..:(
>>
>> But I love the name JSONiq. It?s nice, and it?s cool, and more original
>> then JQuery.
>>
>> If I remember correctly, it was Jonathan Robie?s idea !
>>
>> Dana
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/0a36d4d6/attachment.html>

From dflorescu at me.com  Thu May 28 11:19:51 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 11:19:51 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
Message-ID: <DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>

Ihe,

I am not sure I understand what you mean?

XQuery was baptized XQuery around 2001, when no JSON was around (yet)?.

True that JSON was created later in the same year 2001, however  it did not become widely popular 
about until much later. 

The json.org <http://json.org/>  WS was created in 2002.

We cold have called it TheQuery :-)

Dana


> On May 28, 2015, at 2:01 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> If XQuery had been called  JQuery people would have rushed to learn it before they realised what it was. By which time it would have been too late.
> 
> On Mon, May 25, 2015 at 9:29 AM, Ihe Onwuka <ihe.onwuka at gmail.com <mailto:ihe.onwuka at gmail.com>> wrote:
> No I meant not calling XQuery JQuery. I believe there was time for that....... just imagine......
> 
> On Sat, May 23, 2015 at 2:17 AM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> Bigger mistake
>> 
>> Not calling it JQuery.\
> 
> Ihe,
> 
> the second mistake you mention, not calling it JQuery.
> 
> I wish we could?. but JQuery was used for something else, alas:(
> 
> We didn?t have that choice?..:(
> 
> But I love the name JSONiq. It?s nice, and it?s cool, and more original then JQuery.
> 
> If I remember correctly, it was Jonathan Robie?s idea !
> 
> Dana
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/00de6927/attachment.html>

From ihe.onwuka at gmail.com  Thu May 28 11:59:23 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 28 May 2015 14:59:23 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
Message-ID: <CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>

On Thu, May 28, 2015 at 2:19 PM, daniela florescu <dflorescu at me.com> wrote:

> Ihe,
>
> I am not sure I understand what you mean?
>

Well I'm being slightly tongue in cheek wise after the event.


>
> XQuery was baptized XQuery around 2001, when no JSON was around (yet)?.
>
>
No  Java was ......



> True that JSON was created later in the same year 2001, however  it did
> not become widely popular
> about until much later.
>
>
....but Java was already very very popular.

Now supposing an individual had cobbled together a language in 10 days that
was so crap that it's leading protagonist actually had to write a book
highlighting it's good parts. Read the first paragraph here.

https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript

Imagine if they left the name as LiveScript or ECMAScript and note in the
last sentence of paragraph 1 why they didn't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/58c0cc79/attachment.html>

From dflorescu at me.com  Thu May 28 13:17:04 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 13:17:04 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of
	XQuery	3.1
In-Reply-To: <CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
Message-ID: <A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>

> 
>  
> 
> XQuery was baptized XQuery around 2001, when no JSON was around (yet)?.
> 
> 
> No  Java was ??

Java had at that time it?s own query language, actually made by some people originally involved with XQuery.
https://docs.oracle.com/javaee/6/tutorial/doc/bnbtg.html

> 
>  
> True that JSON was created later in the same year 2001, however  it did not become widely popular 
> about until much later. 
> 
> 
> ....but Java was already very very popular.
> 
> Now supposing an individual had cobbled together a language in 10 days that was so crap that it's leading protagonist actually had to write a book highlighting it's good parts. Read the first paragraph here.
> 
> https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript <https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript> 
> 
> Imagine if they left the name as LiveScript or ECMAScript and note in the last sentence of paragraph 1 why they didn?t.

That?s funny and interesting from a historical point of view.

But that?s water under the bridge.

============

The question for me is what could XQuery ? and all the hard years of heavy experience that we all acquired in querying and processing, indexing, etc for schema-less data  during 18 years ? bring to the world of NoSQL query languages, which, today, is pretty pathetic. 


Best regards
Dana









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/b19e3938/attachment.html>

From ihe.onwuka at gmail.com  Thu May 28 22:03:30 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 01:03:30 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
Message-ID: <CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>

On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com> wrote:

>
> But I see my role as an engineer to build good engineering solutions, not
> to increase the IQ of the general population. That?s not my job.
>
>
But you are not producing solutions for other engineers.

If you tell a developer with zero engineering qualifications their design
is structurally flawed or that they are using the wrong tools they (or
their boss) will turn around and tell you  that there are several ways of
doing things and theirs is equally valid...... and that's if they are being
polite.

Then a couple of epochs and a failed project later they will get feted for
writing a blog about how you shouldn't use what they used or shouldn't do
what they did. Most probably said blog will focus on the effects of what
they did because they probably still don't understand the cause.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/7b0d8359/attachment.html>

From jhunter at servlets.com  Thu May 28 22:06:37 2015
From: jhunter at servlets.com (Jason Hunter)
Date: Fri, 29 May 2015 13:06:37 +0800
Subject: [xquery-talk] Reminder: Subscriber-only posting
Message-ID: <FD6034CD-AAF4-4912-9316-391696747D31@servlets.com>

Just a friendly reminder to people on this list that if you have multiple email addresses, you need to post to the mailing list from the one that's actually subscribed.  If you post from one of your email addresses that isn't exactly the same as the one subscribed, then the list software will reject your mail.

I know it's more fun to imagine a conspiracy, though.

-jh-



From dflorescu at me.com  Thu May 28 22:22:18 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 22:22:18 -0700
Subject: [xquery-talk] Reminder: Subscriber-only posting
In-Reply-To: <FD6034CD-AAF4-4912-9316-391696747D31@servlets.com>
References: <FD6034CD-AAF4-4912-9316-391696747D31@servlets.com>
Message-ID: <C5B2D218-BC53-4FA2-AB6B-9EDFAE30E5A9@me.com>

Jason,

would you please stop the bullshit, please !?

Should I send you all the traces all of the tests that I did sending emails to talk at x-query.com  in the past 48 hours  -- ALL FROM THE SAME ACCOUNT !???

Or better, because this email list is unreliable..... I'll out on a Web page with all of those for everyone to see.

Is there SUCH a big coincidence that I sent emails to this list for almost 10 years and it NEVER happened to have an email rejected until two days ago... 
just after a called your CEO an uneducated dude, who better reads some literature before opening his mouth.

You guys have NO SHAME.

Dana




> On May 28, 2015, at 10:06 PM, Jason Hunter <jhunter at servlets.com> wrote:
> 
> Just a friendly reminder to people on this list that if you have multiple email addresses, you need to post to the mailing list from the one that's actually subscribed.  If you post from one of your email addresses that isn't exactly the same as the one subscribed, then the list software will reject your mail.
> 
> I know it's more fun to imagine a conspiracy, though.
> 
> -jh-
> 
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From dflorescu at me.com  Thu May 28 22:26:05 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 22:26:05 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
Message-ID: <873A7D7C-8B38-4BD2-96FC-85B7D990360C@me.com>

Ihe,

my response to your email did not make it though the list.... so your answer to my answer ..... is not understandable to anyone.

Dana


> On May 28, 2015, at 10:03 PM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> 
> On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
> 
> But I see my role as an engineer to build good engineering solutions, not to increase the IQ of the general population. That?s not my job.
> 
> 
> But you are not producing solutions for other engineers.
> 
> If you tell a developer with zero engineering qualifications their design is structurally flawed or that they are using the wrong tools they (or their boss) will turn around and tell you  that there are several ways of doing things and theirs is equally valid...... and that's if they are being polite.  
> 
> Then a couple of epochs and a failed project later they will get feted for writing a blog about how you shouldn't use what they used or shouldn't do what they did. Most probably said blog will focus on the effects of what they did because they probably still don't understand the cause.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/98b0107c/attachment.html>

From dflorescu at me.com  Thu May 28 22:28:43 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 22:28:43 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
Message-ID: <87922D97-FEFB-42DC-B2D6-7852069E42D0@me.com>

This email was sent this morning.

Obviously, for "different accounts" reasons, it didn't make it through. Yeah. 

Dana


> On May 28, 2015, at 2:43 PM, daniela florescu <dflorescu at me.com> wrote:
> 
>> 
>> 
>> It proves that when it comes to IT you can put lipstick on a pig. If you were trying to name the language today JShit would probably market test better than XQuery.
> 
> 
> That?s why I?m so tired of the database ?science? and the database ?scientific? community, and I run away to 3D and Augmented reality ? which is at the beginning,
> nobody makes billions (yet) and there is still some love of technology, some honesty and integrity, and deep, serious enthusiasm.  There is still some innocence...
> 
> Right now the ?database market? is just lipstick on a (VERY LARGE) pig. Lots of money spent on marketing scream, and unfortunately developers flock like sheep
>  towards the ones who scream the most, without any clue of ?why?.
> 
> Yet we have no clue why a solution is better then other, no benchmarks, just hacky solutions, or temporary solutions which will disappear in 5-10 years, etc.
> 
>> Maybe it's because of your abhorrence of stupidity you tend not to stick around long enough to witness just how stupid some people are.
> 
> Well, I am VERY patient when I want to.... I did stay with the XML community since 1997, despite my deep dislike for processing instructions... :-)
> 
> But I see my role as an engineer to build good engineering solutions, not to increase the IQ of the general population. That?s not my job.
> 
> Best regards
> Dana
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/ac53912c/attachment.html>

From ihe.onwuka at gmail.com  Thu May 28 22:29:09 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 01:29:09 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
Message-ID: <CALfs7+w1Sqr2T6i_mPDKJF8z1qYfhHnW2EvTqGw+eJSYurUAHg@mail.gmail.com>

But you are not producing solutions for other engineers.

If you tell a developer with zero engineering qualifications their design
is structurally flawed or that they are using the wrong tools they (or
their boss) will turn around and tell you  that there are several ways of
doing things and theirs is equally valid...... and that's if they are being
polite.

Then a couple of epochs and a failed project later they will get feted for
writing a blog about how you shouldn't use what they used or shouldn't do
what they did. Most probably said blog will focus on the effects of what
they did because they probably still don't understand the cause.

On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com> wrote:

>
>>
> It proves that when it comes to IT you can put lipstick on a pig. If you
> were trying to name the language today JShit would probably market test
> better than XQuery.
>
>
>
> That?s why I?m so tired of the database ?science? and the database
> ?scientific? community, and I run away to 3D and Augmented reality ? which
> is at the beginning,
> nobody makes billions (yet) and there is still some love of technology,
> some honesty and integrity, and deep, serious enthusiasm.  There is still
> some innocence...
>
> Right now the ?database market? is just lipstick on a (VERY LARGE) pig.
> Lots of money spent on marketing scream, and unfortunately developers flock
> like sheep
>  towards the ones who scream the most, without any clue of ?why?.
>
> Yet we have no clue why a solution is better then other, no benchmarks,
> just hacky solutions, or temporary solutions which will disappear in 5-10
> years, etc.
>
> Maybe it's because of your abhorrence of stupidity you tend not to stick
> around long enough to witness just how stupid some people are.
>
>
> Well, I am VERY patient when I want to.... I did stay with the XML
> community since 1997, despite my deep dislike for processing
> instructions... :-)
>
> But I see my role as an engineer to build good engineering solutions, not
> to increase the IQ of the general population. That?s not my job.
>
> Best regards
> Dana
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/3b06fdf2/attachment.html>

From dflorescu at me.com  Thu May 28 22:33:50 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 22:33:50 -0700
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
Message-ID: <8E8C1FA4-6C55-4CD8-B4DD-9354E64DA782@me.com>

Another message that I sent this morning, and it didn't make it though.....until now.

Thanks Marklogic for opening up the blockade.

I guess the MarkLogic  lawyers needed a little bit of time to scratch their heads about what to do.....(and BTW,
silencing me isn't a solution... I lived in a communist country for 22 years... they've tried that ... didn't work)

But the following message is a serious discussion about the state of affairs in the query languages universe for NoSQL
databases.


> On May 28, 2015, at 2:20 PM, daniela florescu <dflorescu at me.com> wrote:
> 
> The NoSQl industry is extremely successful, used everywhere, and  considered by many the child prodigee of the database industry.
> 
> 
> They are proud of themselves because they satisfy user needs, aka:  they store data:
> (a) which is not in 1st normal form (aka nested, pre-aggregated)
> (b) without schema
> 
> ?to the practical  benefit of:
> (a) the application getting the data out of the database exactly as the application needs it, and not 
> altered through a normalization phase.
> (b) the lack of fixed schema helps with data flexibility? things change extremely quickly inside an application
> those days (fields being added, deleted, changed, etc)
> 
> 
> So far so good, and I think until here they are all right.
> 
> [[ One may think that this looks a little bit like ? XML, but hey, they don?t like XML. Fine.]]
> 
> The problems comes when they try to QUERY this data.
> 
> 
> The NoSQL industry is re-inventing the wheel from scratch, and in a very chaotic and ad-hoc manner.
> 
> Just  look at the sad state of affairs in terms of  query languages and their semantics.
> 
> I am just look at the ones who claim that they can store nested and schema-less data (JSON-like, or XML-lIke)
> 
> (1) MongoDB
> http://docs.mongodb.org/manual/tutorial/query-documents/ <http://docs.mongodb.org/manual/tutorial/query-documents/>
> 
> Note: pure JSON. Couldn?t find a simple sort, for example. Etc. Etc.
> 
> (2) Cassandra/DataStax
> http://www.datastax.com/wp-content/uploads/2013/03/cql_3_ref_card.pdf <http://www.datastax.com/wp-content/uploads/2013/03/cql_3_ref_card.pdf>
> 
> Nore: not even an OR, or a NOT. And does it mean to sort on schema-less data ?
> 
> (3) Spark/DataBricks
> https://databricks.com/blog/2015/02/02/an-introduction-to-json-support-in-spark-sql.html <https://databricks.com/blog/2015/02/02/an-introduction-to-json-support-in-spark-sql.html>
> 
> Note: sounds more like an import/export facility? but they call it a JSON Query language
> 
> (4) Elastic Search
> https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html <https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html>
> 
> Note: very sophisticated full text,but not structured search of any serious kind. Just some simple aggregates (sum, etc)
> 
> 
> (5) Mulesoft
> https://www.mulesoft.com/press-center/new-release-june-2015?utm_source=linkedin&sthash.axJqiSBn.mjjo <https://www.mulesoft.com/press-center/new-release-june-2015?utm_source=linkedin&sthash.axJqiSBn.mjjo>
> 
> Note: not only they seem to have their own JSON query language, but even their own XML query language, it seems. couldn?t find more details.
> 
> (6) Hive
> https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF <https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF>
> 
> Note: multiple languages (Xpath, some json, some SQL, glued together somehow chaotically)
> 
> I can fill in tons of pages with YET-ANOTHER-LANGUGAGE-LIKE-THIS. 
> 
> (7) MarkLogic
> 
> https://docs.marklogic.com/8.0/guide/app-dev/json <https://docs.marklogic.com/8.0/guide/app-dev/json>
> 
> 
> 
> ==============
> 
> Now I can spot several mistake here:
> 
> 1. None of those query language has a clearly designed, mathematical data model. in the absence of such a data model, that describes the input, the output
> and the intermediate results of a query, how can we define a clean semantics ?
> 
> 2. All of them have a hacky semantics ? ?let?s run it and we?ll se what the result is? kind of thing. The semantics in most cost corner cases ? and by definition
> semi-structured data is ONLY corner cases -- is not defined.
> 
> 3. Some try to piggy back on the SQL semantics, ignoring the fact that the SQL was designed to work on relations, and JSON (or in general, nested data) 
> has nothing to do with relations.  SQL semantics cannot be ?ported??.just because we reuse the same keywords.
> 
> 4. None attempted to define a type system (even a basic one for atomic types like dates, and arithmetics on them..) and a schema language.
> 
> ==============
> 
> 
> Now maybe it?s clear why I am so sad that the XQuery community, instead of trying to help the younger and naive NoSQL community, which still believes that
> SQL is ?good enough?, and using the SELECT-FROM-WHERE keywords is the magic bullet to define the semantics of any kind of query language, the XQuery community
>  is still looking at their own navel, and marveling, like the well known CEO: "we can handle flexible data" !!!
> 
> Just compare those languages I listed above with the work that has been done in the past 16 years in XQuery, and the correctness and the complexity of the result
> vs, the hacky solutions above.
> 
> P.S. And yes, that work from XQuery was used 100% in the design of JSONiq, which was designed with the dual goal in mind:
> (a) reuse 100% of the experience of design and implementation of XQuery and
> (b) provide a query language that is synactically and semantically acceptable for the JSON community.
> 
> if we succeeded or not, that?s another story, but I am not aware of any other solution that even comes CLOSE to that goal.
> 
> 
> Best regards
> Dana
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/5748807e/attachment.html>

From dflorescu at me.com  Thu May 28 22:55:37 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 22:55:37 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of
	XQuery	3.1
In-Reply-To: <CALfs7+w1Sqr2T6i_mPDKJF8z1qYfhHnW2EvTqGw+eJSYurUAHg@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+w1Sqr2T6i_mPDKJF8z1qYfhHnW2EvTqGw+eJSYurUAHg@mail.gmail.com>
Message-ID: <93065B37-E822-4FAC-9FA9-CCBC99BC4FC4@me.com>

How about starting tomorrow we allow random people from the street, without any medical qualifications, to start 
doing heart surgery at the Stanford Medical School !???

Or we allow anybody from the street, without any architectural or structural mechanics qualifications to start building bridges in San Francisco !?

Or tomorrow I'll show up at the San Francisco airport and tell them that I'm the one piloting the plane to New York !?

===========

Bottom line...only in software such an aberration is tolerated.....

Dana



> On May 28, 2015, at 10:29 PM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> But you are not producing solutions for other engineers.
> 
> If you tell a developer with zero engineering qualifications their design is structurally flawed or that they are using the wrong tools they (or their boss) will turn around and tell you  that there are several ways of doing things and theirs is equally valid...... and that's if they are being polite.  
> 
> Then a couple of epochs and a failed project later they will get feted for writing a blog about how you shouldn't use what they used or shouldn't do what they did. Most probably said blog will focus on the effects of what they did because they probably still don't understand the cause.
> 
> On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> 
>> It proves that when it comes to IT you can put lipstick on a pig. If you were trying to name the language today JShit would probably market test better than XQuery.
> 
> 
> That?s why I?m so tired of the database ?science? and the database ?scientific? community, and I run away to 3D and Augmented reality ? which is at the beginning,
> nobody makes billions (yet) and there is still some love of technology, some honesty and integrity, and deep, serious enthusiasm.  There is still some innocence...
> 
> Right now the ?database market? is just lipstick on a (VERY LARGE) pig. Lots of money spent on marketing scream, and unfortunately developers flock like sheep
>  towards the ones who scream the most, without any clue of ?why?.
> 
> Yet we have no clue why a solution is better then other, no benchmarks, just hacky solutions, or temporary solutions which will disappear in 5-10 years, etc.
> 
>> Maybe it's because of your abhorrence of stupidity you tend not to stick around long enough to witness just how stupid some people are.
> 
> Well, I am VERY patient when I want to.... I did stay with the XML community since 1997, despite my deep dislike for processing instructions... :-)
> 
> But I see my role as an engineer to build good engineering solutions, not to increase the IQ of the general population. That?s not my job.
> 
> Best regards
> Dana
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/12aeafa7/attachment.html>

From dflorescu at me.com  Thu May 28 14:20:10 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 14:20:10 -0700
Subject: [xquery-talk] the sad state of query languages for semi-structured
 data in the NoSQL industry
Message-ID: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>

The NoSQl industry is extremely successful, used everywhere, and  considered by many the child prodigee of the database industry.


They are proud of themselves because they satisfy user needs, aka:  they store data:
(a) which is not in 1st normal form (aka nested, pre-aggregated)
(b) without schema

?to the practical  benefit of:
(a) the application getting the data out of the database exactly as the application needs it, and not 
altered through a normalization phase.
(b) the lack of fixed schema helps with data flexibility? things change extremely quickly inside an application
those days (fields being added, deleted, changed, etc)


So far so good, and I think until here they are all right.

[[ One may think that this looks a little bit like ? XML, but hey, they don?t like XML. Fine.]]

The problems comes when they try to QUERY this data.


The NoSQL industry is re-inventing the wheel from scratch, and in a very chaotic and ad-hoc manner.

Just  look at the sad state of affairs in terms of  query languages and their semantics.

I am just look at the ones who claim that they can store nested and schema-less data (JSON-like, or XML-lIke)

(1) MongoDB
http://docs.mongodb.org/manual/tutorial/query-documents/ <http://docs.mongodb.org/manual/tutorial/query-documents/>

Note: pure JSON. Couldn?t find a simple sort, for example. Etc. Etc.

(2) Cassandra/DataStax
http://www.datastax.com/wp-content/uploads/2013/03/cql_3_ref_card.pdf <http://www.datastax.com/wp-content/uploads/2013/03/cql_3_ref_card.pdf>

Nore: not even an OR, or a NOT. And does it mean to sort on schema-less data ?

(3) Spark/DataBricks
https://databricks.com/blog/2015/02/02/an-introduction-to-json-support-in-spark-sql.html <https://databricks.com/blog/2015/02/02/an-introduction-to-json-support-in-spark-sql.html>

Note: sounds more like an import/export facility? but they call it a JSON Query language

(4) Elastic Search
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html <https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html>

Note: very sophisticated full text,but not structured search of any serious kind. Just some simple aggregates (sum, etc)


(5) Mulesoft
https://www.mulesoft.com/press-center/new-release-june-2015?utm_source=linkedin&sthash.axJqiSBn.mjjo <https://www.mulesoft.com/press-center/new-release-june-2015?utm_source=linkedin&sthash.axJqiSBn.mjjo>

Note: not only they seem to have their own JSON query language, but even their own XML query language, it seems. couldn?t find more details.

(6) Hive
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF <https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF>

Note: multiple languages (Xpath, some json, some SQL, glued together somehow chaotically)

I can fill in tons of pages with YET-ANOTHER-LANGUGAGE-LIKE-THIS. 

(7) MarkLogic

https://docs.marklogic.com/8.0/guide/app-dev/json



==============

Now I can spot several mistake here:

1. None of those query language has a clearly designed, mathematical data model. in the absence of such a data model, that describes the input, the output
and the intermediate results of a query, how can we define a clean semantics ?

2. All of them have a hacky semantics ? ?let?s run it and we?ll se what the result is? kind of thing. The semantics in most cost corner cases ? and by definition
semi-structured data is ONLY corner cases -- is not defined.

3. Some try to piggy back on the SQL semantics, ignoring the fact that the SQL was designed to work on relations, and JSON (or in general, nested data) 
has nothing to do with relations.  SQL semantics cannot be ?ported??.just because we reuse the same keywords.

4. None attempted to define a type system (even a basic one for atomic types like dates, and arithmetics on them..) and a schema language.

==============


Now maybe it?s clear why I am so sad that the XQuery community, instead of trying to help the younger and naive NoSQL community, which still believes that
SQL is ?good enough?, and using the SELECT-FROM-WHERE keywords is the magic bullet to define the semantics of any kind of query language, the XQuery community
 is still looking at their own navel, and marveling, like the well known CEO: "we can handle flexible data" !!!

Just compare those languages I listed above with the work that has been done in the past 16 years in XQuery, and the correctness and the complexity of the result
vs, the hacky solutions above.

P.S. And yes, that work from XQuery was used 100% in the design of JSONiq, which was designed with the dual goal in mind:
(a) reuse 100% of the experience of design and implementation of XQuery and
(b) provide a query language that is synactically and semantically acceptable for the JSON community.

if we succeeded or not, that?s another story, but I am not aware of any other solution that even comes CLOSE to that goal.


Best regards
Dana











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/14b64e70/attachment.html>

From ihe.onwuka at gmail.com  Thu May 28 14:23:48 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 28 May 2015 17:23:48 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
Message-ID: <CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>

On Thu, May 28, 2015 at 4:17 PM, daniela florescu <dflorescu at me.com> wrote:

>
>
>
>>
>> XQuery was baptized XQuery around 2001, when no JSON was around (yet)?.
>>
>>
> No  Java was ??
>
>
> Java had at that time it?s own query language, actually made by some
> people originally involved with XQuery.
> https://docs.oracle.com/javaee/6/tutorial/doc/bnbtg.html
>
>

But they didn't call it JQuery, so the name was still available


>
>
>
>> True that JSON was created later in the same year 2001, however  it did
>> not become widely popular
>> about until much later.
>>
>>
> ....but Java was already very very popular.
>
> Now supposing an individual had cobbled together a language in 10 days
> that was so crap that it's leading protagonist actually had to write a book
> highlighting it's good parts. Read the first paragraph here.
>
> https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript
>
> Imagine if they left the name as LiveScript or ECMAScript and note in the
> last sentence of paragraph 1 why they didn?t.
>
>
> That?s funny and interesting from a historical point of view.
>
> But that?s water under the bridge.
>
>
It proves that when it comes to IT you can put lipstick on a pig. If you
were trying to name the language today JShit would probably market test
better than XQuery.

This is the discipline supposedly grounded in logic, but you know the
saying - "The Cobblers children are always the worst shod".



> The question for me is what could XQuery ? and all the hard years of heavy
> experience that we all acquired in querying and processing, indexing, etc
> for schema-less data  during 18 years ? bring to the world of NoSQL query
> languages, which, today, is pretty pathetic.
>
>
We are in an age where people who never knew what it was like before SQL (I
really should say RDBMS) are making decisions on database architecture.
Remember this (I got it from your linkedin feed)
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ .
I read it and thought DUHHHHH!!!!! but I knew it would be eulogized by
other readers (sure enough look in the comments). That's the world we are
in today.

The things you talk about with XQuery solve problems that todays architects
don't know they have. People are  busy latching onto NoSQL performance
benchmarks, without having a clue of the price that was extracted to get
 those figures. Because the understanding of many developers today does not
go much deeper than the manipulation of syntax NoSQL vendors can get away
with passing these huge compromises  off as a virtue ("We don't support
joins, isn't that great").

Maybe it's because of your abhorrence of stupidity you tend not to stick
around long enough to witness just how stupid some people are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/a9f1d9d6/attachment.html>

From dflorescu at me.com  Thu May 28 14:43:01 2015
From: dflorescu at me.com (daniela florescu)
Date: Thu, 28 May 2015 14:43:01 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
Message-ID: <0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>

> 
> 
> It proves that when it comes to IT you can put lipstick on a pig. If you were trying to name the language today JShit would probably market test better than XQuery.


That?s why I?m so tired of the database ?science? and the database ?scientific? community, and I run away to 3D and Augmented reality ? which is at the beginning,
nobody makes billions (yet) and there is still some love of technology, some honesty and integrity, and deep, serious enthusiasm.  There is still some innocence...

Right now the ?database market? is just lipstick on a (VERY LARGE) pig. Lots of money spent on marketing scream, and unfortunately developers flock like sheep
 towards the ones who scream the most, without any clue of ?why?.

Yet we have no clue why a solution is better then other, no benchmarks, just hacky solutions, or temporary solutions which will disappear in 5-10 years, etc.

> Maybe it's because of your abhorrence of stupidity you tend not to stick around long enough to witness just how stupid some people are.

Well, I am VERY patient when I want to.... I did stay with the XML community since 1997, despite my deep dislike for processing instructions... :-)

But I see my role as an engineer to build good engineering solutions, not to increase the IQ of the general population. That?s not my job.

Best regards
Dana







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150528/dfa32e54/attachment.html>

From ihe.onwuka at gmail.com  Fri May 29 01:34:16 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 04:34:16 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <93065B37-E822-4FAC-9FA9-CCBC99BC4FC4@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+w1Sqr2T6i_mPDKJF8z1qYfhHnW2EvTqGw+eJSYurUAHg@mail.gmail.com>
	<93065B37-E822-4FAC-9FA9-CCBC99BC4FC4@me.com>
Message-ID: <CALfs7+y7XLPN2JRc2wvSWQOFjKVv0utdR1Smj=m6T_XNQsmxjA@mail.gmail.com>

On Fri, May 29, 2015 at 1:55 AM, daniela florescu <dflorescu at me.com> wrote:

> How about starting tomorrow we allow random people from the street,
> without any medical qualifications, to start
> doing heart surgery at the Stanford Medical School !???
>
> Or we allow anybody from the street, without any architectural or
> structural mechanics qualifications to start building bridges in San
> Francisco !?
>
> Or tomorrow I'll show up at the San Francisco airport and tell them that
> I'm the one piloting the plane to New York !?
>
> ===========
>
> Bottom line...only in software such an aberration is tolerated.....
>
>
Because unlike in the other instances the true effect of software designed
by amateurs  lies latent and is usually neither  immediately nor outwardly
apparent.

Tolerated is the wrong word. The entire industry has coalesced around
technologies and methodologies designed to enable the amateur coder to
write professional software and these are the people  that determine the
fate of your engineering solution and what tools and methods you are going
to have to work with. Look  at the recent changes in MarkLogic and you can
clearly see where they try to cater to that demographic. Or look at Apache
Spark - built in Scala - do you think their support for Scala emanates from
engineering considerations.

So then you have an environment in which it is more important to know how
to use these tools and methods than it is to have a fundamental
understanding of what it is you are doing. As an example (he says
deliberately avoiding ones close to home), look at Data Science. Industry
is such that it is more important to know how to program in R than it is to
have a basic understanding of Statistics, but the nature of the output they
produce is such that the effects of such practices will remain camouflaged
for a long time to come (or until the UK has another general election). R
in particular is one to watch, because of all the hype you have a
confluence of people who know little about Statistics and even less about
programming.

I could go on..... the reality is that today people today want to query
 semi-structured data in Javascript, Python and R and you can't look to
their management because  this is the first generation that grew up with
 managers that did not have a computer science or engineering background.

So sadly Daniela, politics and populism trump engineering and not enough
lives are at risk in what we do for that to ever change. The choice is to
come to terms with it, go back to research or find something else to do.















> Dana
>
>
>
> On May 28, 2015, at 10:29 PM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
>
> But you are not producing solutions for other engineers.
>
> If you tell a developer with zero engineering qualifications their design
> is structurally flawed or that they are using the wrong tools they (or
> their boss) will turn around and tell you  that there are several ways of
> doing things and theirs is equally valid...... and that's if they are being
> polite.
>
> Then a couple of epochs and a failed project later they will get feted for
> writing a blog about how you shouldn't use what they used or shouldn't do
> what they did. Most probably said blog will focus on the effects of what
> they did because they probably still don't understand the cause.
>
> On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com>
> wrote:
>
>>
>>>
>> It proves that when it comes to IT you can put lipstick on a pig. If you
>> were trying to name the language today JShit would probably market test
>> better than XQuery.
>>
>>
>>
>> That?s why I?m so tired of the database ?science? and the database
>> ?scientific? community, and I run away to 3D and Augmented reality ? which
>> is at the beginning,
>> nobody makes billions (yet) and there is still some love of technology,
>> some honesty and integrity, and deep, serious enthusiasm.  There is still
>> some innocence...
>>
>> Right now the ?database market? is just lipstick on a (VERY LARGE) pig.
>> Lots of money spent on marketing scream, and unfortunately developers flock
>> like sheep
>>  towards the ones who scream the most, without any clue of ?why?.
>>
>> Yet we have no clue why a solution is better then other, no benchmarks,
>> just hacky solutions, or temporary solutions which will disappear in 5-10
>> years, etc.
>>
>> Maybe it's because of your abhorrence of stupidity you tend not to stick
>> around long enough to witness just how stupid some people are.
>>
>>
>> Well, I am VERY patient when I want to.... I did stay with the XML
>> community since 1997, despite my deep dislike for processing
>> instructions... :-)
>>
>> But I see my role as an engineer to build good engineering solutions, not
>> to increase the IQ of the general population. That?s not my job.
>>
>> Best regards
>> Dana
>>
>> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/6be4b37e/attachment.html>

From ihe.onwuka at gmail.com  Fri May 29 01:35:55 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 04:35:55 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+y7XLPN2JRc2wvSWQOFjKVv0utdR1Smj=m6T_XNQsmxjA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+w1Sqr2T6i_mPDKJF8z1qYfhHnW2EvTqGw+eJSYurUAHg@mail.gmail.com>
	<93065B37-E822-4FAC-9FA9-CCBC99BC4FC4@me.com>
	<CALfs7+y7XLPN2JRc2wvSWQOFjKVv0utdR1Smj=m6T_XNQsmxjA@mail.gmail.com>
Message-ID: <CALfs7+zAfhp1O=RCri=1wH9LovUjYm4o1Mdpzcmo2-zZ8kdS-A@mail.gmail.com>

On Fri, May 29, 2015 at 4:34 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

>
>
> On Fri, May 29, 2015 at 1:55 AM, daniela florescu <dflorescu at me.com>
> wrote:
>
>> How about starting tomorrow we allow random people from the street,
>> without any medical qualifications, to start
>> doing heart surgery at the Stanford Medical School !???
>>
>> Or we allow anybody from the street, without any architectural or
>> structural mechanics qualifications to start building bridges in San
>> Francisco !?
>>
>> Or tomorrow I'll show up at the San Francisco airport and tell them that
>> I'm the one piloting the plane to New York !?
>>
>> ===========
>>
>> Bottom line...only in software such an aberration is tolerated.....
>>
>>
> Because unlike in the other instances the true effect of software designed
> by amateurs  lies latent and is usually neither  immediately nor outwardly
> apparent.
>
> Tolerated is the wrong word. The entire industry has coalesced around
> technologies and methodologies designed to enable the amateur coder to
> write professional software and these are the people  that determine the
> fate of your engineering solution and what tools and methods you are going
> to have to work with. Look  at the recent changes in MarkLogic and you can
> clearly see where they try to cater to that demographic. Or look at Apache
> Spark - built in Scala - do you think their support for Scala emanates from
> engineering considerations.
>
>
that should read ... do you think their support for Python emanates from
engineering considerations.



> So then you have an environment in which it is more important to know how
> to use these tools and methods than it is to have a fundamental
> understanding of what it is you are doing. As an example (he says
> deliberately avoiding ones close to home), look at Data Science. Industry
> is such that it is more important to know how to program in R than it is to
> have a basic understanding of Statistics, but the nature of the output they
> produce is such that the effects of such practices will remain camouflaged
> for a long time to come (or until the UK has another general election). R
> in particular is one to watch, because of all the hype you have a
> confluence of people who know little about Statistics and even less about
> programming.
>
> I could go on..... the reality is that today people today want to query
>  semi-structured data in Javascript, Python and R and you can't look to
> their management because  this is the first generation that grew up with
>  managers that did not have a computer science or engineering background.
>
> So sadly Daniela, politics and populism trump engineering and not enough
> lives are at risk in what we do for that to ever change. The choice is to
> come to terms with it, go back to research or find something else to do.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> Dana
>>
>>
>>
>> On May 28, 2015, at 10:29 PM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
>>
>> But you are not producing solutions for other engineers.
>>
>> If you tell a developer with zero engineering qualifications their design
>> is structurally flawed or that they are using the wrong tools they (or
>> their boss) will turn around and tell you  that there are several ways of
>> doing things and theirs is equally valid...... and that's if they are being
>> polite.
>>
>> Then a couple of epochs and a failed project later they will get feted
>> for writing a blog about how you shouldn't use what they used or shouldn't
>> do what they did. Most probably said blog will focus on the effects of what
>> they did because they probably still don't understand the cause.
>>
>> On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com>
>> wrote:
>>
>>>
>>>>
>>> It proves that when it comes to IT you can put lipstick on a pig. If you
>>> were trying to name the language today JShit would probably market test
>>> better than XQuery.
>>>
>>>
>>>
>>> That?s why I?m so tired of the database ?science? and the database
>>> ?scientific? community, and I run away to 3D and Augmented reality ? which
>>> is at the beginning,
>>> nobody makes billions (yet) and there is still some love of technology,
>>> some honesty and integrity, and deep, serious enthusiasm.  There is still
>>> some innocence...
>>>
>>> Right now the ?database market? is just lipstick on a (VERY LARGE) pig.
>>> Lots of money spent on marketing scream, and unfortunately developers flock
>>> like sheep
>>>  towards the ones who scream the most, without any clue of ?why?.
>>>
>>> Yet we have no clue why a solution is better then other, no benchmarks,
>>> just hacky solutions, or temporary solutions which will disappear in 5-10
>>> years, etc.
>>>
>>> Maybe it's because of your abhorrence of stupidity you tend not to stick
>>> around long enough to witness just how stupid some people are.
>>>
>>>
>>> Well, I am VERY patient when I want to.... I did stay with the XML
>>> community since 1997, despite my deep dislike for processing
>>> instructions... :-)
>>>
>>> But I see my role as an engineer to build good engineering solutions,
>>> not to increase the IQ of the general population. That?s not my job.
>>>
>>> Best regards
>>> Dana
>>>
>>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/18dbbde2/attachment.html>

From ihe.onwuka at gmail.com  Fri May 29 01:51:27 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 04:51:27 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+y7XLPN2JRc2wvSWQOFjKVv0utdR1Smj=m6T_XNQsmxjA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+w1Sqr2T6i_mPDKJF8z1qYfhHnW2EvTqGw+eJSYurUAHg@mail.gmail.com>
	<93065B37-E822-4FAC-9FA9-CCBC99BC4FC4@me.com>
	<CALfs7+y7XLPN2JRc2wvSWQOFjKVv0utdR1Smj=m6T_XNQsmxjA@mail.gmail.com>
Message-ID: <CALfs7+zE1myMB7OCzLs99AWuCk+=QNccNdiRy+sv_K3OLtDKDg@mail.gmail.com>

On Fri, May 29, 2015 at 4:34 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

>
>
>> I could go on..... the reality is that today people today want to query
>  semi-structured data in Javascript, Python and R and you can't look to
> their management because  this is the first generation that grew up with
>  managers that did not have a computer science or engineering background.
>
>
Honourable mentions should go out to the hard sciences and quantitative
disciplines.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/2e12d635/attachment.html>

From CMisztur at macleanfogg.com  Fri May 29 05:08:07 2015
From: CMisztur at macleanfogg.com (Misztur, Chris)
Date: Fri, 29 May 2015 12:08:07 +0000
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <8E8C1FA4-6C55-4CD8-B4DD-9354E64DA782@me.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>,
	<8E8C1FA4-6C55-4CD8-B4DD-9354E64DA782@me.com>
Message-ID: <B5851F8C-7476-40E5-8BCB-B451FBD7E9AF@macleanfogg.com>

thanks

________________________________

The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author.

Please consider the environment before printing this e-mail



From ihe.onwuka at gmail.com  Fri May 29 06:12:27 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 09:12:27 -0400
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
Message-ID: <CALfs7+x_UrDE1a2Np5OyquceVCGG1JsH59V95MGy+U8nGPyLKQ@mail.gmail.com>

On Thu, May 28, 2015 at 5:20 PM, daniela florescu <dflorescu at me.com> wrote:

> The NoSQl industry is extremely successful, used everywhere, and
>  considered by many the child prodigee of the database industry.
>
>
I could have sworn it is the unacknowledged hip but bastard grandchild of
the network and hierarchical databases of the 60's and 70's.... so correct
me where I am wrong in what follows.


>
> They are proud of themselves because they satisfy user needs, aka:  they
> store data:
> (a) which is not in 1st normal form (aka nested, pre-aggregated)
> (b) without schema
>
> ?to the practical  benefit of:
> (a) the application getting the data out of the database exactly as the
> application needs it, and not
> altered through a normalization phase.
>

Which can give you blazing fast  performance IFF. But to take an example
from my movie project. We have stored movie reviews by critic. You pull up
a page for the critic and get all the movie reviews he has ever written.
Then the client suddenly turns around (as mine did) and says I want to pull
up the movie and get all the reviews the different critics have written.
That query isn't going to be fast, and if you are not working with a proper
query language it might not be straightforward to write. So not only do you
not get a free lunch on the performance, you mind end up with a double
whammy.

In that sense nothing has changed  from db's of 60's and 70's .

Enter relational and you had (after normalisation) a database design that
was neutral to the queries that were to be run as there was no nesting. In
addition you got a proper relational query language and  something very
important - query optimisation (in theory at least) for free.


> (b) the lack of fixed schema helps with data flexibility? things change
> extremely quickly inside an application
> those days (fields being added, deleted, changed, etc)
>
>
How much data independence does that afford you.


>
> So far so good, and I think until here they are all right.
>
> [[ One may think that this looks a little bit like ? XML, but hey, they
> don?t like XML. Fine.]]
>
> The problems comes when they try to QUERY this data.
>
>
> The NoSQL industry is re-inventing the wheel from scratch, and in a very
> chaotic and ad-hoc manner.
>
> Just  look at the sad state of affairs in terms of  query languages and
> their semantics.
>
> <snipped/>
>
> ==============
>
> Now I can spot several mistake here:
>
> 1. None of those query language has a clearly designed, mathematical data
> model. in the absence of such a data model, that describes the input, the
> output
> and the intermediate results of a query, how can we define a clean
> semantics ?
>
> 2. All of them have a hacky semantics ? ?let?s run it and we?ll se what
> the result is? kind of thing. The semantics in most cost corner cases ? and
> by definition
> semi-structured data is ONLY corner cases -- is not defined.
>
> 3. Some try to piggy back on the SQL semantics, ignoring the fact that the
> SQL was designed to work on relations, and JSON (or in general, nested
> data)
> has nothing to do with relations.  SQL semantics cannot be ?ported??.just
> because we reuse the same keywords.
>
>
A big reason why people in Analytics who know what they are talking about
are keen to use SQL is because you get query optimisation for free.



> 4. None attempted to define a type system (even a basic one for atomic
> types like dates, and arithmetics on them..) and a schema language.
>
> Now maybe it?s clear why I am so sad that the XQuery community, instead of
> trying to help the younger and naive NoSQL community, which still believes
> that
> SQL is ?good enough?, and using the SELECT-FROM-WHERE keywords is the
> magic bullet to define the semantics of any kind of query language, the
> XQuery community
>  is still looking at their own navel, and marveling, like the well known
> CEO: "we can handle flexible data" !!!
>
> Just compare those languages I listed above with the work that has been
> done in the past 16 years in XQuery, and the correctness and the complexity
> of the result
> vs, the hacky solutions above.
>
> P.S. And yes, that work from XQuery was used 100% in the design of JSONiq,
> which was designed with the dual goal in mind:
> (a) reuse 100% of the experience of design and implementation of XQuery and
> (b) provide a query language that is synactically and semantically
> acceptable for the JSON community.
>
>
It's called Javascript. Also known as Python.


> if we succeeded or not, that?s another story, but I am not aware of any
> other solution that even comes CLOSE to that goal.
>
>
They don't share that goal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/21ff4894/attachment.html>

From dflorescu at me.com  Fri May 29 07:47:09 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 29 May 2015 07:47:09 -0700
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <CALfs7+x_UrDE1a2Np5OyquceVCGG1JsH59V95MGy+U8nGPyLKQ@mail.gmail.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
	<CALfs7+x_UrDE1a2Np5OyquceVCGG1JsH59V95MGy+U8nGPyLKQ@mail.gmail.com>
Message-ID: <A8185240-DA6F-4767-B4EC-A9EFDBB7EBD0@me.com>

> 
> P.S. And yes, that work from XQuery was used 100% in the design of JSONiq, which was designed with the dual goal in mind:
> (a) reuse 100% of the experience of design and implementation of XQuery and
> (b) provide a query language that is synactically and semantically acceptable for the JSON community.
> 
> 
> It's called Javascript. Also known as Python.
>  

A query language like ?? hum ?.. Javascript or Phyton !???

In this email I am only talking about query languages, Ihe. See the definition here:
http://en.wikipedia.org/wiki/Query_language <http://en.wikipedia.org/wiki/Query_language>

Best regards
Dana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/7f89e682/attachment.html>

From ihe.onwuka at gmail.com  Fri May 29 07:53:24 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 10:53:24 -0400
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <A8185240-DA6F-4767-B4EC-A9EFDBB7EBD0@me.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
	<CALfs7+x_UrDE1a2Np5OyquceVCGG1JsH59V95MGy+U8nGPyLKQ@mail.gmail.com>
	<A8185240-DA6F-4767-B4EC-A9EFDBB7EBD0@me.com>
Message-ID: <CALfs7+z4mwK3NcHDX+WJ=8uS3sBUOnH7T-si4jrNdLbXBz2-zQ@mail.gmail.com>

Daniela, you forgot to switch your irony detecting gene on.






On Fri, May 29, 2015 at 10:47 AM, daniela florescu <dflorescu at me.com> wrote:

>
>> P.S. And yes, that work from XQuery was used 100% in the design of
>> JSONiq, which was designed with the dual goal in mind:
>> (a) reuse 100% of the experience of design and implementation of XQuery
>> and
>> (b) provide a query language that is synactically and semantically
>> acceptable for the JSON community.
>>
>>
> It's called Javascript. Also known as Python.
>
>
>
> A query language like ?? hum ?.. Javascript or Phyton !???
>
> In this email I am only talking about query languages, Ihe. See the
> definition here:
> http://en.wikipedia.org/wiki/Query_language
>
> Best regards
> Dana
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/05084cdc/attachment.html>

From dflorescu at me.com  Fri May 29 07:54:16 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 29 May 2015 07:54:16 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of
	XQuery	3.1
In-Reply-To: <CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
Message-ID: <52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>


> On May 28, 2015, at 10:03 PM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> 
> On Thu, May 28, 2015 at 5:43 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
> 
> But I see my role as an engineer to build good engineering solutions, not to increase the IQ of the general population. That?s not my job.
> 
> 
> But you are not producing solutions for other engineers.

As often as I hear that statement, I ignore at equally often.

Stubborn as I am, yes, I will CONTINUE to produce good solutions, designed for ENGINEERS, not for morons without any
engineering qualifications (but who build complex database applications).

I?ll leave that task to MarkLogic to ?satisfy" the moron population and offer them Javascript as a server side query language.

As usually those are in larger numbers then the good engineers, MarkLogic will make more money ?..I guess.

But that?s not my goal, so I?m fine with that.

Again, stubborn as I am, my goal is to design good solutions for good engineers.


Best regards
Dana


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/c9d05cd8/attachment.html>

From dflorescu at me.com  Fri May 29 08:02:46 2015
From: dflorescu at me.com (daniela florescu)
Date: Fri, 29 May 2015 08:02:46 -0700
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <CALfs7+z4mwK3NcHDX+WJ=8uS3sBUOnH7T-si4jrNdLbXBz2-zQ@mail.gmail.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
	<CALfs7+x_UrDE1a2Np5OyquceVCGG1JsH59V95MGy+U8nGPyLKQ@mail.gmail.com>
	<A8185240-DA6F-4767-B4EC-A9EFDBB7EBD0@me.com>
	<CALfs7+z4mwK3NcHDX+WJ=8uS3sBUOnH7T-si4jrNdLbXBz2-zQ@mail.gmail.com>
Message-ID: <544386D5-A76B-416E-858C-14271D7597BA@me.com>

The humor gene is here. But recent events made my sense of humor become a little dry.

So, if you want a technical discussion, let?s have technical discussion.

Best regards
Dana



> On May 29, 2015, at 7:53 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> Daniela, you forgot to switch your irony detecting gene on. 
> 
> 
> 
> 
> 
> 
> On Fri, May 29, 2015 at 10:47 AM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> P.S. And yes, that work from XQuery was used 100% in the design of JSONiq, which was designed with the dual goal in mind:
>> (a) reuse 100% of the experience of design and implementation of XQuery and
>> (b) provide a query language that is synactically and semantically acceptable for the JSON community.
>> 
>> 
>> It's called Javascript. Also known as Python.
>>  
> 
> A query language like ?? hum ?.. Javascript or Phyton !???
> 
> In this email I am only talking about query languages, Ihe. See the definition here:
> http://en.wikipedia.org/wiki/Query_language <http://en.wikipedia.org/wiki/Query_language>
> 
> Best regards
> Dana
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/b2484470/attachment.html>

From ihe.onwuka at gmail.com  Fri May 29 09:14:38 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Fri, 29 May 2015 12:14:38 -0400
Subject: [xquery-talk] the sad state of query languages for
 semi-structured data in the NoSQL industry
In-Reply-To: <544386D5-A76B-416E-858C-14271D7597BA@me.com>
References: <8CC1DACA-711D-462B-9559-EC2C7CF98A12@me.com>
	<CALfs7+x_UrDE1a2Np5OyquceVCGG1JsH59V95MGy+U8nGPyLKQ@mail.gmail.com>
	<A8185240-DA6F-4767-B4EC-A9EFDBB7EBD0@me.com>
	<CALfs7+z4mwK3NcHDX+WJ=8uS3sBUOnH7T-si4jrNdLbXBz2-zQ@mail.gmail.com>
	<544386D5-A76B-416E-858C-14271D7597BA@me.com>
Message-ID: <CALfs7+weUjYuwxuFKD4X6BQGxwii=vGr1PP4iW7H90mgNVJTRw@mail.gmail.com>

On Fri, May 29, 2015 at 11:02 AM, daniela florescu <dflorescu at me.com> wrote:

> The humor gene is here. But recent events made my sense of humor become a
> little dry.
>
> So, if you want a technical discussion, let?s have technical discussion.
>
>
For that to be really interesting you need to find somebody who disagrees
with you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150529/4c1bdc26/attachment.html>

From ihe.onwuka at gmail.com  Fri May 29 23:40:08 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Sat, 30 May 2015 02:40:08 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
	<52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
Message-ID: <CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>

On Fri, May 29, 2015 at 10:54 AM, daniela florescu <dflorescu at me.com> wrote:

>
> But that?s not my goal, so I?m fine with that.
>
> Again, stubborn as I am, my goal is to design good solutions for good
> engineers.
>
>
Great. Well JSONiq is my tool of choice for dealing with JSON.

Can you provide any insights to the graph database landscape. A
conversation on xml-dev with Peter Hunsberger has persuaded me that a dual
representation (XML for serving data and graph for running algorithms) is
probably what I need but I prefer to have some basis for evaluation before
jumping in with any particular product.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150530/b6def71b/attachment.html>

From dflorescu at me.com  Sat May 30 09:42:25 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 30 May 2015 09:42:25 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
	<52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
	<CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>
Message-ID: <94B38E75-1911-4514-8C2A-696FC77E177B@me.com>

> 
> 
> Great. Well JSONiq is my tool of choice for dealing with JSON. 
> 
> Can you provide any insights to the graph database landscape. A conversation on xml-dev with Peter Hunsberger has persuaded me that a dual representation (XML for serving data and graph for running algorithms) is probably what I need but I prefer to have some basis for evaluation before jumping in with any particular product.

Unfortunately I cannot help you here. I tried to keep up with the graph languages, but lost it at some
point. Things are moving too fast. 

And unlike NoSQL query languages, where the situation is really pathetic, the graph languages and their implementations
are not that bad, I think. So there are reasonable choices...

Sorry for not helping,
Dana


P.S. 20 years ago I wrote a paper about a graph language (we thought at that time that semi-stuctured data will necessarily be a graph?)
 which kind of influenced the design of SPARQL.
http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf <http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf>

But of course, this is no help to you, other then intellectual curiosity :-)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150530/946fbd86/attachment.html>

From ihe.onwuka at gmail.com  Sat May 30 10:45:04 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Sat, 30 May 2015 13:45:04 -0400
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <94B38E75-1911-4514-8C2A-696FC77E177B@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
	<52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
	<CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>
	<94B38E75-1911-4514-8C2A-696FC77E177B@me.com>
Message-ID: <CALfs7+xA+-5w1VUMuZ2hn=zdeRgbxyf45cr_u9D5gUHMq9dXxA@mail.gmail.com>

On Sat, May 30, 2015 at 12:42 PM, daniela florescu <dflorescu at me.com> wrote:

>
>>
> Great. Well JSONiq is my tool of choice for dealing with JSON.
>
> Can you provide any insights to the graph database landscape. A
> conversation on xml-dev with Peter Hunsberger has persuaded me that a dual
> representation (XML for serving data and graph for running algorithms) is
> probably what I need but I prefer to have some basis for evaluation before
> jumping in with any particular product.
>
>
> Unfortunately I cannot help you here. I tried to keep up with the graph
> languages, but lost it at some
> point. Things are moving too fast.
>
> And unlike NoSQL query languages, where the situation is really pathetic,
> the graph languages and their implementations
> are not that bad, I think. So there are reasonable choices...
>

Ok back to these NoSql offerings I have a question.

You are always telling these vendors that their products are not databases
they are data stores. Now from that and the limited amount i have read (it
is difficult to continue reading beyond the point where you know this is
not a product you want to use) it sounds like these products are little
more than glorified VSAM files.

I get why SQL is not an appropriate basis for a language for these data
stores but I don't yet see how we make the leap from XQuery being a
language for particular types of semi-structured data to it being the basis
of a query language suitable for semi-structured data in principle, unless
you are talking in very broad terms about the features such a query
language should have and what principles should guide it's design.



>
> P.S. 20 years ago I wrote a paper about a graph language (we thought at
> that time that semi-stuctured data will necessarily be a graph?)
>  which kind of influenced the design of SPARQL.
>
> http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf
>
> But of course, this is no help to you, other then intellectual curiosity
> :-)
>
>
People who are not intellectually curious end up writing blogs about why
you should not do what they did. Then again they also get the kudos of
being  invited to give talks about their cock-ups to other people who are
not intellectually curious but want to learn from the bitter experience of
others.

But  yes i will try and give it a read.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150530/8087bbf8/attachment.html>

From dflorescu at me.com  Sat May 30 11:12:23 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 30 May 2015 11:12:23 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of XQuery
	3.1
In-Reply-To: <CALfs7+xA+-5w1VUMuZ2hn=zdeRgbxyf45cr_u9D5gUHMq9dXxA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
	<52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
	<CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>
	<94B38E75-1911-4514-8C2A-696FC77E177B@me.com>
	<CALfs7+xA+-5w1VUMuZ2hn=zdeRgbxyf45cr_u9D5gUHMq9dXxA@mail.gmail.com>
Message-ID: <2478EED7-85EB-4F10-9125-B8AC9663841C@me.com>

I will give you a somewhat short answer to that question but we can expand only if necessary.

**********
True in general for every query language
**********

1. In general I think a ?query? language should be functional and compositional.
(besides having a high expressive power, it has other advantages like being able to do data flow analysis
through the function invocations ? which is necessary for almost EVERYTHING inside a database,
 from logging to index detection to optimizability)

SQL got only a ?little? but of comparability only after decades of existence?.for my taste it?s really clunky.
I never remember what I can compose with what ? and never understand why not !??

2. In general a query language should have the FLWOR-like  expression  (called it as you like, SELECT-FROM-WHERE
whatever). In mathematics (or theoretical computer science) it is called monoid comprehension. 

The more powerful the FLWOR like expression, the more expressive power of the query language.

I think XQuery has the best designed expression of this kind in existence. It?s compositional, elegant, symmetrical.
The semantics is very well defined, and ? if you look well? NOWHERE IN THE DEFINITION OF THE SEMANTICS
OF THE FLOWR EXPRESSION THE WORD XML OCCURS.

The FLWOR expression of XQuery is a construct that has NOTHING to do with XML !!

3. In general, a query language is not a query language unless is optimizable.(aka the ability for a compiler to be able to 
derive from one syntax many different ways of evaluating the result, some being more optimal then others).

I think during the design of XQuery a HUGE deal of attention was done to the optimizability of the language. The implementations 
show that we didn?t get it wrong. Most implementations have decent response time (even though alas, there is no standard benchmark).


***************
Things that are absolutely necessary for semi-structured query languages
**************

1.Conditionals, typeswitches

In schema-less data, we never know what we?ll find. We HAVE to be able to branch based on what we find in the data while searching.

2. Functions and recursive functions

While dealing with nested, pre-aggregated data, we need to navigate structures on unknown depth, and for this we really need functions
and recursive functions.

3. Error management: try/catch

Even with the best precautions, while dealing with data of unknown structure, we can ALWAYS find unexpected stuff: an integer when we 
thought we?ll get a string, and we try to cast it to a date. Hence, an error.

Imagine you processed already 1 million rows, and suddenly one of those rows is ?bad?. In the absence of a try/catch the whole result will be an exception
and your hard work on a million rows is lost.


==========

Now those three things: switches of all kinds, recursive functions and error management change the good old query processing DRAMATICALLY.
(why is that ? Because they make difficult the famous data flow analysis I just talked about ? and which is a necessity in any query optimizer).

Relational database optimizers don?t deal with such difficulties, because they didn?t have them.


That?s a short answer of why XQuery is better for processing semi-structured data then any other alternative out there.

Note: REMARK THAT IN THIS WHOLE EMAIL I NEVER PRONOUNCED THE WORD XML.

XQuery, despite it?s very unfortunate name, is NOT an XML query language (ONLY).

It?s basic principles have nothing to do with XML.

That?s why in JSONiq it was trivial to take out the ?/? navigation, replace it with ?.? navigation, replace the node constructors with object
constructors, and here we go.


Best regards
Dana



> On May 30, 2015, at 10:45 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> 
> 
> On Sat, May 30, 2015 at 12:42 PM, daniela florescu <dflorescu at me.com <mailto:dflorescu at me.com>> wrote:
>> 
>> 
>> Great. Well JSONiq is my tool of choice for dealing with JSON. 
>> 
>> Can you provide any insights to the graph database landscape. A conversation on xml-dev with Peter Hunsberger has persuaded me that a dual representation (XML for serving data and graph for running algorithms) is probably what I need but I prefer to have some basis for evaluation before jumping in with any particular product.
> 
> Unfortunately I cannot help you here. I tried to keep up with the graph languages, but lost it at some
> point. Things are moving too fast. 
> 
> And unlike NoSQL query languages, where the situation is really pathetic, the graph languages and their implementations
> are not that bad, I think. So there are reasonable choices...
> 
> Ok back to these NoSql offerings I have a question.
> 
> You are always telling these vendors that their products are not databases they are data stores. Now from that and the limited amount i have read (it is difficult to continue reading beyond the point where you know this is not a product you want to use) it sounds like these products are little more than glorified VSAM files.
> 
> I get why SQL is not an appropriate basis for a language for these data stores but I don't yet see how we make the leap from XQuery being a language for particular types of semi-structured data to it being the basis of a query language suitable for semi-structured data in principle, unless you are talking in very broad terms about the features such a query language should have and what principles should guide it's design.
> 
> 
> 
> 
> P.S. 20 years ago I wrote a paper about a graph language (we thought at that time that semi-stuctured data will necessarily be a graph?)
>  which kind of influenced the design of SPARQL.
> http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf <http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf>
> 
> But of course, this is no help to you, other then intellectual curiosity :-)
> 
> 
> People who are not intellectually curious end up writing blogs about why you should not do what they did. Then again they also get the kudos of being  invited to give talks about their cock-ups to other people who are not intellectually curious but want to learn from the bitter experience of others.
> 
> But  yes i will try and give it a read.
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150530/bcb8f1fc/attachment.html>

From dflorescu at me.com  Sat May 30 12:43:57 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 30 May 2015 12:43:57 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of
	XQuery	3.1
In-Reply-To: <2478EED7-85EB-4F10-9125-B8AC9663841C@me.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
	<52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
	<CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>
	<94B38E75-1911-4514-8C2A-696FC77E177B@me.com>
	<CALfs7+xA+-5w1VUMuZ2hn=zdeRgbxyf45cr_u9D5gUHMq9dXxA@mail.gmail.com>
	<2478EED7-85EB-4F10-9125-B8AC9663841C@me.com>
Message-ID: <C472FDB6-0166-4F14-B7BF-A6C1E3FE8844@me.com>

> 
> ***************
> Things that are absolutely necessary for semi-structured query languages
> **************
> 
> 1.Conditionals, typeswitches
> 
> In schema-less data, we never know what we?ll find. We HAVE to be able to branch based on what we find in the data while searching.
> 
> 2. Functions and recursive functions
> 
> While dealing with nested, pre-aggregated data, we need to navigate structures on unknown depth, and for this we really need functions
> and recursive functions.
> 
> 3. Error management: try/catch


In this list I forgot something really important for any kind of query language for semi-strcutured data;

4. A battery of implicit type conversions.

Data being of unexpected shape and type, we can never be sure that the data operations get at runtime is what you expected when you wrote the query.

Defining those is an **ART** (with capitals:-), because one need to make a compromise between:
- not being too strict, otherwise everything ends up in an error
- not being too lax ("anything goes" kind of thing), because you introduce errors in the resulting data
- making sure that the implicit type conversion are done such that you can STILL use indexes (if you index a value as an integer and at runtime it gets converted and 
used as string in an equality? are you still able to use the index !?)
-usability and symmetry ; such implicit conversions happen in a variety of places (function calls, equality, arithmetics, groupby, sort, etc, etc) and you have to make sure that
they are kind of symmetrical and obey the ?principle of least surprise?  and also allow optimizability, aka expression rewriting

At least 25% of the design of XQuery has spent in the design of this battery of implicit type conversions.

I think the result is decent. I am not ware of any major mistake, that I wish we would have done better, or differently. But everything was design by trail, design, implementation, usage, error, 
designe, implementation, etc, etc. That?s why it took an eternity to design them, and for XQuery to get standardized.

I honestly don?t wish even my worst enemy to start this process from scratch, and I wish the NoSQL community would have learned from what we?ve done.

Wishful thinking on Saturday morning, best regards
Dana





From dflorescu at me.com  Sat May 30 13:17:42 2015
From: dflorescu at me.com (daniela florescu)
Date: Sat, 30 May 2015 13:17:42 -0700
Subject: [xquery-talk] [xml-dev] Mistakes made in the design of
	XQuery	3.1
In-Reply-To: <CALfs7+xA+-5w1VUMuZ2hn=zdeRgbxyf45cr_u9D5gUHMq9dXxA@mail.gmail.com>
References: <01C44C03-4AE1-4963-8EAF-95383D9F85DF@me.com>
	<D6B2CE26-EA1E-4638-866D-7FE97B792783@me.com>
	<609E3A26-09E0-4E9D-AA96-AC631E5260A1@saxonica.com>
	<7CDBC143-C916-4036-983B-ED7C4DBDC15E@me.com>
	<8438CC1D-ED46-439A-B527-C2076CBF70FE@saxonica.com>
	<69764608-6EDF-429D-BF15-3249A38299C1@me.com>
	<2C9E1628-BCC7-4312-8BB9-8BB44729B5DA@me.com>
	<DA19C06F-5E84-4BE4-B854-422A2829B2FF@saxonica.com>
	<AE81E92E-C1E2-4B04-9CBB-131BCF048705@me.com>
	<CALfs7+wVaDhF6LRuHVOSOhX+MOhqq3UvNcokvjX2aUMSqtNqXw@mail.gmail.com>
	<73D1B46A-4F65-4BAD-BCF9-A5BE691B3697@me.com>
	<CALfs7+xUkvktjR5TE_6M3smBvN4LMSJaeLqOh-W9OhAvq1Vc8A@mail.gmail.com>
	<CALfs7+yUdupEPL5CS6YPfOjDG0Ek1XO1Oj-AQkPUgaPo0Pb2rA@mail.gmail.com>
	<9193A25D-08C7-4D60-B945-D440077D91C3@me.com>
	<55533E14.3070603@benibela.de>
	<E80DDA28-CB69-491F-BCB5-AEA648D9C6F3@me.com>
	<CALfs7+y7SO-g_ch+qBAfwQVgJViwpyX7Gg7tt3pVEpTAfS59yQ@mail.gmail.com>
	<2B7D30C9-3EE8-4820-A045-79679BE5A56C@me.com>
	<CALfs7+zxJrTz+7gq0z=WiaQEPAGVEDZwVOGBQFNMgwVoUnrV9A@mail.gmail.com>
	<CALfs7+y+yZ7kuuY=8=f6BSBKZcqQzDXmX2gY7cEiuVvUU_3OjQ@mail.gmail.com>
	<DFAA5D74-EC69-4121-8EC6-849AB2A40E37@me.com>
	<CALfs7+w0zB4bS4=Z7pjPB48BpBTwdW+9kxoewK-x4wV+cwLe9g@mail.gmail.com>
	<A383CC4A-A21A-4474-816C-849FA1369BF5@me.com>
	<CALfs7+wciOgtTmoknAt78KrwFu-58xjep6j5qG_rAM+Vp5Yipw@mail.gmail.com>
	<0C57C6BA-EBEA-470E-8848-59DBE865AA8E@me.com>
	<CALfs7+wZ8byiz1A9F1OoRsG3WjPmB9arF6TfmBQk3JqWm0ZO+Q@mail.gmail.com>
	<52C4390A-030B-4A7A-B7DA-55D53480A68B@me.com>
	<CALfs7+wkdrXprnRLhHRM0gbOdxUxoyq7JVVdJPTtCcQ9jGJJKw@mail.gmail.com>
	<94B38E75-1911-4514-8C2A-696FC77E177B@me.com>
	<CALfs7+xA+-5w1VUMuZ2hn=zdeRgbxyf45cr_u9D5gUHMq9dXxA@mail.gmail.com>
Message-ID: <E59507D0-AADF-46D9-B3E4-2A3F8963BD4B@me.com>

> 
> I get why SQL is not an appropriate basis for a language for these data stores but I don't yet see how we make the leap from XQuery being a language for particular types of semi-structured data to it being the basis of a query language suitable for semi-structured data in principle, unless you are talking in very broad terms about the features such a query language should have and what principles should guide it's design.

Ihe,

I gave you a general answer in the previous emails.

Yet I have to remark something before I shut up.

Our work in JSONiq applies to JSON. Period.

Not all NoSQL databases use JSON as a data model (or syntax, whatever) - some use it just a simple 
add-on, or import/export syntax, similar to CSV.

The problem of building a good query language for those NoSQL databases starts with the fact that 
THEY HAVE NO CLEAR DATA MODEL of the data they store. Not even sometimes of what basic types
they can store (e.g. ask Cassandra people if they can store dates, and you?ll get a very convoluted answer?)

Most of the times the ?data model? is just an implicit assumption behind the API calls that you can make to that database/datastore.

I don?t know how to build a good query language, unless I have a logical model of the data being queried? it?s that simple.

At least JSON? I understand JSON? so I can build a query language for it?.

It?s not a value judgment  (aka "JSON is better?), it?s just that it?s there, it?s well described, and people use it everywhere.

Best regards
Dana




From ihe.onwuka at gmail.com  Sun May 31 13:23:45 2015
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Sun, 31 May 2015 16:23:45 -0400
Subject: [xquery-talk] some thought about NoSQL query processing in the
	form of a talk
In-Reply-To: <6EEF68A7-23C0-4C0E-B8CA-AE8B6F456B95@me.com>
References: <6EEF68A7-23C0-4C0E-B8CA-AE8B6F456B95@me.com>
Message-ID: <CALfs7+xM=Qyoq0KuKnc0S8zo3+kayd3tkH6f++dYL_DR3SmBPA@mail.gmail.com>

Some observations, mostly inspired by your other posts which are still
giving me food for thought.

History always has valuable lessons to teach us. If you look at the NOSQL
landscape in terms of players it is not dissimilar to the landscape in the
early relational era (which includes the non-relational vendor).

Many of those companies had success, rapid growth and then either got too
uppity or made a strategic error and were acquired, often  by Computer
Associates (Cullinet, ADR, ingres) but IBM swallowed up Informix and Sybase
became SQL/Server. The few  vendors survive standalone today that I can
think of, Software AG, Cincom and Information Builders were mostly set up
in late 60's early 70's. There is no reason not to expect  a similar
rationalisation (of both product and vendor) in the NoSQL arena. Commercial
considerations aside too much of it is built on the two biggest hype
machines of the moment - Big Data and JSON.

JSON advocates have been allowed to present the format as an alternative to
XML and more appropriate in certain use cases (I forget which because I
don't really care). This is not true (actually it's a big fat lie) because
in many domains (e.g where precision is required, wherever there is
regulatory oversight or where your use of data could lead to an expensive
lawsuit) JSON is simply not an option. I don't think this is widely
appreciated yet but if and when the tech bubble bursts the money will be in
servicing these areas that are no go for JSON .

RDBMS took off when the biggest kid in the playground IBM jumped in with
DB2. IBM made the mistake of leaving the relational market on Unix and
Windows markets open to other vendors (like Oracle), but it's questionable
if there would ever have been an Oracle if IBM had not paved the way for
the acceptance of relational products with DB2. One thing IBM never did is
bet against it's own technology which is what MarkLogic seem to be doing by
with it's support for Javascript.

True times are different and IBM did not have to cope with the offerings of
an open source movement  but a moments thought will reveal some possible
potholes here. We all heard the mutterings against MarkLogic because of
difficulties with the (Oba.....Affordable Care Act) website and inviting
every Javascript coder off the street to build on your platform (because
that's effectively what they have done) could lead to other bad PR
debacles. As the XML community have found with JSON PR machine, it doesn't
have to be true, or even justified, it just has to stick.






2015-05-30 14:13 GMT-04:00 daniela florescu <dflorescu at me.com>:

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150531/cdeca046/attachment.html>