The current introduction is unclear and lacks references.
I will pass reviewing this, sorry.
I’m accepting this, but I’m curious about the paragraph of why graph query languages cannot work properly with tree/hierarchical data (which is a subset of DAG)
Unfortunately, I’m not going to be able to review this. However, having quickly looked at the changes in the commits, I would kindly suggest that introduction is focused on what benefits AQL provides, rather than build a narrative around the claim that every other significant option is broken.
I would not be willing to make the kind of strong statements in these commits without references to publications, but that’s me. To say that SQL does not provide query portability would raise some eyebrows from the members of the SQL standard committee members.
I added the introduction to try to orient newcomers on the main question: why does AQL exist? So in some sense, it does have to say why not SQL, GraphQL, Sparql etc. I think it needs to mention the main aims of AQL:
not to be based on physical schemas, but instead on a semantic model
to enable portable queries (due to the first point).
Happy to fix anything you thing is wrong. A few points:
I guess SQL could at a stretch occasionally be portable if queries are designed against some sort of common view table definition, but I’ve never heard of any wide use of such an approach;
things like GraphQL could be modified to work with archetype-based data, but I don’t see how they would work directly - it would need to be via a JSON transform of the data, but then you’d be using it to mimic AQL, just in a painful way.
Anyway, proposed improvements are welcome (including to fix any statements you think are incorrect). It’s not meant to be a dissertation on query languages - just an orientation for people who probably know other QLs on AQL.
Some adjustments in latest commit.