W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

The URI vs. IDREF problem

From: Gregor Karlinger <Gregor.Karlinger@iaik.at>
Date: Wed, 12 Jan 2000 11:55:20 +0100
Message-ID: <387C5D98.6E37ECDE@iaik.at>
To: "Joseph M. Reagle Jr." <reagle@w3.org>
CC: ML W3C XML-Signature <w3c-ietf-xmldsig@w3.org>
As can be read in [1] there is currently the consideration wheter to
skip the IDREF "shortcut" attribute of element Reference, or to keep
the current definition.

If we decide to skip the IDREF attribute, I see two possibilities
for the URI attribute:

a) Allow URI also to be a URI-Reference (conforming with the Schema
   datatype "uri" - please see [2])

   In this case, if a fragment identifier exists as part of the 
   URI-Reference, this fragment identifier should be seen as
   a shortcut for applying a XPath Transform with the fragment
   identifier as parameter. This Transform has to be the first
   transform applied to the content referred to by the Reference.
   Otherwhise the problems John Boyer mentioned in [3] will appear.

b) Do not allow URI to be a URI-Reference  

   In this case, the only way to select parts of a XML document
   is to specify a XPath Transform in the Reference's Transforms
   element.

In both cases it is necessary to employ a XPath Transform if one wants
to select a part of a XML document by referring to the Id attribute
of an element, i.e. allowing a fragment identifier is not really a
shortcut.

I think solution b) is much cleaner, since it does not specify any redundancies.  
 

Gregor

-----
[1] http://www.w3.org/Signature/Minutes/000106-tele.html
[2] http://www.w3.org/TR/xmlschema-2/#uri
[3] Message on this list titled "Difficulties with URI="" and IDREF"
    from John Boyer, dated 03.01.00, 19:51

---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------



Received on Wednesday, 12 January 2000 05:55:44 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT