>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
This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT