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/
