Comments below.
I suggest the OMML be more general rather than restricitng it to
the proxylet. Maybe the root element can be OpesIrInfo with a type
attribute specifying if it is a proxylet, ICAPcallout etc.
Also, doesn't the description attribute belong in this element rather
than in the owner element (as intuitively it does not
describe the owner)
Yes, good suggestions.
It was restricted to the proxylet because we defined the "proxylet:"
URI scheme in this ID, but OMML should cover the full OPES functionality.
Section 5.2 (There is some numbering mistake, but 5.2 is unique)
seems to be incomplete. Was the intention to specify how the rules
specified in the metadata gets "and"ed with the rules in the rule module ?
If not, what was the intention and where will this "and"ing be specified ?
(The DTD as written has no way of specifying these additional rules)
Rule requirements specific to the proxylet/ICAP/... defined in OMML,
that will later be "and"ed with the rule module were intentionally left
out of this version of the ID due to lack of time to update the doc,
plus felt we didn't yet have consensus. And since an ID is one way to
reach consensus, we'll add it soon -:)
Re: modified-header element, should we have a special header value of
"any"
or do we allow regexp and have the user specify * ?
I'll propose allowing regexp as keywords are more restrictive.
protocols
Thanks
Christian