- From: John Boyer <jboyer@uwi.com>
- Date: Thu, 14 Oct 1999 07:58:29 -0700
- To: "Joseph M. Reagle Jr." <reagle@w3.org>
- Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 11:25 99/10/08 -0700, John Boyer wrote: >a) Section 4.3.1 Location does not say whether it will allow fragment Ids >after the the URI. It would probably make a better data model if we did all >partial document work in the transformations (and this could be treated as a >special transformation that is required as opposed to recommended). I think I agree with this. In the HTML context that which comes after a URI is merely a "view" on the whole document, and thinking that way in our context can be dangerous; I like transformations. But I also understand Don's point that we still need to refer to objects elsewhere in the document. However, I think this can be satisfied by saying the location must be a URI-clean or IDREF [1]. <John> I suppose the point I am making (which Don also made in a recent email) is that semantically there is no semantic difference between putting the ID fragment in a transformation versus putting it after the URI. If you want to refer to something in the same document, you could represent this using <Location></Location> <Transformations> <Transformation Algorith="urn:dsig:xpointer">SomeID</Transformation> </Transformations> or with <Type>text/xml</Type> <Location>#SomeID</Location> The latter is shorter, but it mucks up the data model. The former is longer but cleaner in so many ways. John Boyer Software Development Manager UWI.Com -- The Internet Forms Company </John> This seems like an abitrary restriction though, and if someone puts and XPtr in their URI and also specify a XSLT, we need to define what happens, or say that the signature engine will throw an error. [1] http://www.xml.com/axml/notes/FindingIDs.html _________________________________________________________ Joseph Reagle Jr. Policy Analyst mailto:reagle@w3.org XML-Signature Co-Chair http://w3.org/People/Reagle/
Received on Thursday, 14 October 1999 10:58:04 UTC