[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt





On 19/12/2007, at 12:12 PM, Brian Smith wrote:


Mark Nottingham wrote:

I-D ACTION:draft-nottingham-atompub-fiql-00.txt
FYI; I'd love any feedback folks have on this.

Why not XPath or XQuery or SPARQL (with an Atom/RDF mapping), or CSS
selectors or some subset of one of those?

In a nutshell, there are two reasons;

1) Those query languages are optimised for data models that aren't feeds; respectively, XML Infosets, Infosets again, RDF graphs and CSS cascades. While it's possible to contort them to fit feeds, they don't really lend themselves to it. XQuery and SPARQL also present a fairly high barrier to adoption (if you're not a big XML vendor or a SW-head, respectively ;) Contorting them so that they're easy to fit into a URL isn't too attractive, either.

2) When you expose a query interface, you're allowing people to consume compute power on your servers. An arbitrary query language allows arbitrary queries, which is unacceptable when you're working across administrative domains. FIQL gives you tools to constrain how queries are shaped.

I've been asked this many times, and should probably add it as a FAQ in an appendix. Certainly there are use cases for using XQuery, etc. against feeds, but it's also become apparent that there's a place for something simple, reasonably flexible, and Web-friendly.

"By default, a selector is treated as an XML Qname which selects any and
all child elements of the entry element which share the same syntax
(i.e., the same prefix and localname; the namespace URI is not
considered), along with their descendant content if any."

That is not acceptable. First, namespace handling in feed-consuming
software is bad enough as it is.

While true, I don't see how that's relevant.

And, secondly, this provides an
unnuecesssary burden on the server to preserve Qnames and prevent Qname
conflicts.
In my software, I preserve the Qnames of attributes and elements as long
as the underlying XML (SAX and XSLT) stack provides enough information
to preserve them. Unfortunately, a LOT of XML stacks do not provide
enough information to preserve QNames exactly; Python's default SAX
parser (pyexpat) and most XSLT processors (in any language binding)
don't preserve Qnames accurately enough. As a result, the Qname of any
element or attribute might change as it moves between storage and the
HTTP interface and cannot be relied upon.

I'm open to other suggestions, but this seemed to be the simplest way to go about it. Note that the 'name' attribute on the fq:index element gives you a way to specify a stable name for a selector that's independent of the QName; if you're concerned about these issues, you can use that.

Cheers,

--
Mark Nottingham     http://www.mnot.net/