RE: Difficulties with URI="" and IDREF

<John>
Actually, there are three options.

a. (absoluteURI | relativeURI) and IDREF
b. (URI-reference) and no IDREFs
c. (absoluteURI | relativeURI) and use a transform for partial document
access.

The best choice is C.  We currently have A, which has the aforementioned
IDREF problem. Choosing B does not get rid of the IDREF problem from A.  C
eliminates the problem by having element identification occur only through a
*canonicalizing* transform.

Furthermore, I'm sure there will be objections from those who "don't want to
implement c14n" or "don't want to implement XPath support" for the sake of
keeping processing simple on small signatures or just reducing development
time.  Well, once again, these are not valid arguments.  The spec is only
defining what the resultant bytestream has to look like.  If a particular
party's XML is small, it is also quite likely to be simple such that making
the byte stream conform to c14n will be very easy.  As for XPath, full
support is also not needed by a particular app that just wants to verify its
own signatures; it can just look for the particular XPath phrase(s) it
supports.  Only apps that want to do interoperable signatures from among
apps (whose characteristics may not be known in advance) need to support the
full blown versions of the recommended and optional features in the spec.

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

</John>

[1] URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
    http://www.ietf.org/rfc/rfc2396.txt

However, the status of the URI and IDREF was 'lets put it in there, and see
what sort of response we get.' No one seems to be a huge fan from an
elegance point of view. The two options we had of proceeding were as
follows:

a. (absoluteURI | relativeURI) and IDREF
b. (URI-reference) and no IDREFs

(We constrained ourselves so we'd have a single consistent way of doing
something). I'm beginning to think the right interpration would've been B.
(Partly because I don't think we can define a 'clean URI' (without a
fragment) that anyone will pay attention to. The uri schema datatype isn't
defined that way.) No attribute should be definied as an IDREF, instead it
should be defined as a URI. However, this still means that someone can
specify an XPath or an XPtr as part of the URI and also have one as part of
a transform. The consequence of this would be to return to a target
attribute of type attribute, but I'm curious to hear other thoughts.

_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Wednesday, 5 January 2000 16:58:22 UTC