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? I guess one reason is to abstract away Atom vs. RSS and the other reason is that namespace proliferation in Atom/RSS documents is out of control. Those are valid concerns but I think making namespace handling even more insane is not the answer. "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. 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. - Brian
