Have we lost track? (re:location and transforms)

In wading through yesterdays deluge of messages, it seems that we may have lost 
track somewhat of the problem I thought we were solving.  My impression was/is 
that the goal is to be able to create a signature over one or more objects 
(blobs of bits, possibly XML) and to create an XML syntax for carrying the 
signature; ensuring that the signature can't be compromised; and providing 
necessary clues/hints/instructions for relying parties to validate the 
signature.  Any semantics beyond "these are the same bits as the ones signed" 
are left to the application.  Thus, the "location" [certainly a bad choice of 
name, mea culpa], keyInfo, and to a great extent transforms are part of the set 
of clues - not part of the semantics [unless the application decides to do 
more].  That was certainly the intent of the current writeup of the processing 
description.  I like Marc's distinction between transforms to get the object 
and transforms to sign a subset of an object.

Ideally, using the mechanism shouldn't usually (e.g. signing a PDU, signing a 
single complete object/document (plus attributes)) require massive use of 
XPath, XSLT, etc. (although certainly some document related applications will).

It seems to me that if we retain that model (location and transforms are 
clues), we can keep this simple.  Local implementations are free to manage the 
local storage, referencing, etc.  as they see best without violating the 
specification.  Although location and transforms could, in this interpretation, 
be either inside the signature or outside, I think retaining the current syntax 
which aggregates this data in ojbectReference is the cleanest.  Finally, it 
really doesn't matter if you sign the data vs. a digest of the data vs. a 
digest of a digest of the data - so long as the design is sound.

Dave