2533 is similar, but I'd like to see something more like RDF, because
you get to point to globally unique concepts in an unambiguous way (such
as "the HTTP Accept header" ;)
My first inclination in terms of syntax here would be XML, because there
are more tools for working with it, and the size of the rulesets aren't
as critical as with conneg. Others may be just as useful (as long as
we're not inventing a brand-new syntax!)
BTW, this may be interesting input to IRML:
Rule Markup Techniques Workshop
http://www.dfki.uni-kl.de/ruleml/rmt/
(see the program for presentations)
On Tuesday, March 19, 2002, at 06:44 AM, Graham Klyne wrote:
Hmmm...
I'm not familiar with this IRML work, but the keywords "matching" and
"logic" suggest there may be some similarities with the content
negotiation work in RFC 2533. We used an LDAP-based syntax, but XML
could work just as well -- it's all just s-expressions, isn't it?
#g
--
At 07:03 PM 3/18/02 -0800, Mark Nottingham wrote:
On Thursday, March 7, 2002, at 01:14 PM, Andre Beck wrote:
Match seems to have the beginnings of boolean logic embedded; I see
AND (multiple matches specified) and NOT (not-matches) and even OR
(just flattened out to multiple rules). IMHO It would be good if
this were explicit; e.g., <and> ... </and> <or> ... </or> <not> ...
</not> wrappers around matches.
We tried that when we first came up with IRML, but it get's really
messy
if you have a lot of conditions.
Messy in what way? If you mean 'looks/reads messy', I'd ask whether
IRML is supposed to be primarily human-readable or machine-readable.
Ideally, of course, it would be both, but IMHO a machine-unambiguous
representation is better if you have to make a tradeoff; it can always
be presented or transformed to a more human-palatable form. Directly
expressing the boolean logic gives the most clarity and flexibility in
the rules; implying it leads to a less capable and more ambiguous
format, IMO.
Cheers,
--
Mark Nottingham
http://www.mnot.net/
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>