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>