On Thursday, March 7, 2002, at 01:14 PM, Andre Beck wrote:
* Section 3 - Is there any reason a public identifier was chosen
vs. a system identifer? Also, if namespaces are used, they should
always be used, whether the document is a whole ruleset or a
fragment.
Agreed. As for the document identifier: Are there any guidelines as to
when to use a public identifier vs. only a system identifier?
My understanding is that public identifiers are a legacy of SGML, and
weren't expected to be used much except by organisations like the W3C
(as you see in HTML, XHTML, etc.). If the format might be expected to
encounter an SGML processor, it might be good to use a public
identifier; otherwise, a system identifier gives a well-understood way
to find the DTD (i.e., dereference the URI).
Is validation required when parsing an IRML document?
Is the authorized-by element intended to capture the authorisation
state of the ruleset (e.g., the rule processor appends it to the
ruleset upon discovering and verifying the identity and rights of
the submitting process), or is it a placeholder for a mechanism
like XML Digital Signatures?
It's really just a mechanism to allow for the delegation of
authority, e.g. to allow end users to authorize their service
providers to set up IRML rule sets on their behalf which would then be
reflected in the 'authorized-by' element. IRML does not specify how the
authorization state of a rule set is enforced/verified, but this would
probably be a work item for OPES.
OK. I was wondering whether it would be good to completely remove the
authorisation state from the ruleset itself. It might be the case that
you wrap the ruleset in an XML Dig Sig block, but that might be best
thought of as an external process; that way, rulesets can be passed
around without worrying about the authorisation assertions they make (so
that a vendor can distribute default rulesets with products, etc.; rules
have form both before and after they get authorised).
Just thinking out loud, it definitely needs to be considered in a larger
context.
--
Mark Nottingham
http://www.mnot.net/