AW: The XML-DSig Non-standard, or Location/Transforms as 'hints'

	>2) With Location as location (or target as target, it's still a
rose!), 
	>I read the location and dereference.  The application is 
	>not involved in defining how core code digs up X.

	I'd like to design a signature module that doesn't need to know
anything on how to retrieve documents out from a generic location. Not
assuming there only will be http: or one or two more, I would probably have
a retrieval-module that knows how to handle these things. I wouldn't
consider this module not to be application specific but enviroment-specific.
It would know where to look - and it might even look it up in the original
location if required. 

	>The 'Location as hint' solution says that CompanyB should make a
copy of D...
	Nice example. It nicely proves that using an URL for long-term
referencing a document that can change is not a good idea in the first
place.

	>If Date(signed document) < MMDDYYYY, then 
	>	http://www.CompanyA.com/documentD ->
http://www.CompanyB.com/documentD
	>else	http://www.CompanyA.com/documentD ->
http://www.CompanyA.com/documentD
	If both companies had used from the beginning:
	http://www.companyA.com/documentD.MMDDYYYY
	the whole problem is nonexistent. If you use the location as a
location, what would it buy you in your example? The signature still breaks
and you still have no solution to solve the problem....

	>Can you actually write another letter telling me why *this* 
	>interoperability situation is just a figment of my imagination?

	>Because there does seem to be a relatively easy fix,
	> and I can't figure out why this is such a big deal 
	>(so it would be nice to actually discuss that too).
	Still, location as a hint does not hurt here and the only real fix I
see is to properly use URL's.

		Peter