Have you looked at "RFC 2254 - The String Representation of LDAP Search
Filters"? I've used variants of that in URIs before.
Its use of &'s is probably asking for escaping bugs in URIs though.
Some questions and comments -
Attribute matching
Matching atom:category would be useful, but atom:category depends on
attributes - is that
supported at all? Can we have a special element comparison type for
atom:category that supports
attribute matching?
Existence checks
RFC 2254 supports checks that a property (or element) exists or not.
I'd think something like that would be pretty useful. Eg: draft=*
Matching against QNames
QNames are evil. I'd rather have inexact *:name matches, than explicitly
matching against a namespace prefix.
Would it be possible to write qname match predicates, but have the prefix
in the
predicate have no significance, and then optionally allow another type of
predicate,
for the anal, to requre that the prefix to be mapped to a certain URI?
ex:name=="Dave" ; matches *:name, but
ex:name=="Dave",xmlns:ex=="http://example.com/"; ; matches a specific
element.
Person constructs
Do element match predicates only apply to direct children of atom:entry?
Does "email" match
atom:author/atom:email?
Inheritance
Are element match predicates supposed to apply to the logical properties
of the entry
after things like author inheritance rules have been applied?
fq:index
Is the default that no selectors can be used? If you define fq:index
elements
does that mean that only those selectors can be used? Is there anyway to
say that
any selectors can be used?
--
Dave
