Mark Nottingham wrote:
> On 19/12/2007, at 6:54 PM, Brian Smith wrote:
> To my mind, XPath 2.0 (which you seem to be referring to) is
> too complex to base something like this on; printing the
> XQuery-related specs kills too many trees, and it takes a
> major investment to get up to speed with it as a user, much
> less an implementer. While it works if you're already
> invested in the XQuery world, my perception is that this
> group is still fairly small, and "enterprise" focused.
>
> I don't keep up to date with the XQuery world, but last I
> checked, Perl, Python, PHP and Ruby all lacked
> implementations. What will they do?
Parsing that subset of XPath 2.0 might be a little harder than parsing
FIQL, but building parsers is trivial nowadays. Actually implementing
the semantics shouldn't be any harder than implementing FIQL's
semantics, though, since they are equally expressive.
> I'm not married to the current syntax, but I do want it to be
> URI- friendly and easy for humans to understand.
In the syntax you proposed, how can I search for all entries that have a
title starting with an asterisk ('*')? Or, in other words, it isn't
clear to me how you deal with quoting/escaping issues. Is the processor
supposed to treat an percent-encoded asterisk differently from an
unencoded asterisk character? And, if so, how does this interact with
URI templates?
> If the syntax meets those goals and happens to be a
> subset of XPath, I'm fine, but I don't want to define it as
> an explicit subset; doing so will force people to learn
> XPath whether they want to or not, and IMO will lead to
> interop problems as people start relying on Xpath
> features, rather than what the spec says.
There is no point in reusing the XPath syntax if it isn't 100%
upwards-compatible with XPath. If I were to write a specification for
this, the normative text would be written purely in terms of XPath; I
would have a separate non-normative tutorial describing the subset, and
a non-normative XQuery mapping should be included as well.
XPath is incompatible with URI templates; because of the
quoting/escaping requirements for strings, it isn't possible to write a
URI template (as they are defined today) that is guaranteed to result in
a syntactically-valid XPath expression. To see why, try to construct a
URI template that generates an the XPath containing a single quote and a
double quote at the same time, or even just one or the other. This is a
significant limitation of URI templates, and one that is difficult to
solve. Another problem with URI templates is that there is no "listjoin"
operation for dictionaries; this makes it difficult to pass an arbitrary
number of namespace prefix bindings along with the query. Finally, URI
templates cannot deal with nested structures like those used in the
AND/OR expressions in XPath, FIQL, and Gdata.
Besides syntax, I'm also not yet convinced that such a mechanism like
this is really needed. It seems like we can get really far with URI
templates and an explicit enumeration of searchable fields like GData,
if we remove the logical OR operator. And, once you *need* a logical OR
operator, or when you need to be able to search an open-ended set of
fields, you will probably be in a situation where it is worthwhile to
use (a significant of) XPath 1.0, XPath 2.0, XQuery, and/or some other
advanced structured document search language, plus a set of
Atom-specific extension functions. Do you have any real-world motivating
examples of something where a GData-ish query mechanism is insufficient,
but XPath is too much?
- Brian
