RE: Meaning of document closure

Hi Tim,

I guess I could not tell from your letter whether you intended to disagree
with me, but I agree exactly with what you've said in this letter and see it
as further justification for why the WG should proceed in the way we seem to
be proceeding now.

Contrary to implication, the quote you gave of mine was not designed to be
the only type of data interdependency that I could see among elements.  It
was designed to provide a specific 'proof by counterexample' against the
sufficiency of the inclusion logic for document filtering which was actively
being defended in earlier drafts of dsig specs.

Most if not all of my communications about these issues have stated that we
do not have a specific vocabulary in mind, so we need exclusion logic as
well or we will only be able to sign a subset of XML.  If XML permits a data
relationship, then we have to provide a way for the author of a document
filter to capture the data relationship.

This is the more graph theoretic sense which made me choose the word closure
to describe what I mean.  Literally, we are talking about transitive closure
on a digraph of data dependencies, as in obtain the set of elements
'reachable' from a given element by a path of data dependencies.  The
definition I gave in my email is a more practical one whose utility is
easier for the WG to see.  It is the view of document closure as seen by
those who must manipulate documents and construct document filters.  It is a
definition that helps the person understand what they are supposed to do
with the feature.  However, if one says that the entire document must be
scanned and that we should permit precise identification of elements for
exclusion in order to achieve transitive closure on data dependencies, then
it should be clear that either definition implies the other.

So, although we have no knowledge of the XML vocabulary at play and hence
cannot construe any semantics about parts having meaning in context, the
author of the document filter *does* have specific knowledge of the
vocabulary, the semantics and even the specific usage scenarios at play and
thus can construct a signature whose validation is construed as meaning that
the document has not been modified in a meaningful way within the
application context.  The ability to specify the transitive closure of
dependent elements is pretty much the same thing as the ability to specify
what can change after the signature is applied.

In conclusion, I agree with the repeated application of a node test (which
is exactly what the XPath does), I esp. agree that the signature must be
applied to the entire document (which is necessary both for transitive
closure interpretation and for the implementation of exclusion logic), I
obviously agree that exclusion logic is preferrable, I agree that the
document filter is like an application c14nalg (as opposed to an XML
c14nalg), I agree that it is a transformation function, I agree that the
transformed document must include the transformed function in the hash, and
I agree that it is the transformed document must be presented to the user.
Best of all, this is how XFDL operates.

Since we seem to agree on every substantial point (once one looks deeper at
what I've been saying and why it was said in particular ways), I am hoping
you will let me know if I have misinterpreted anything you are saying.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

Received on Monday, 20 September 1999 14:05:02 UTC