Re: A "plug/play" URI/IDREF proposal

At 10:07 00/02/10 +0100, Gregor Karlinger wrote:
 >I have followed up the latest discussion about the URI/IDREF problem and
 >would like to present a proposal which is slightly different from what I
 >have posted in [1] and was referred to by Donald in [2]:
 >
 >  1. Remove the 'IDREF' attribute from the Reference element.
 >
 >  2. Allow the 'URI' attribute of the Reference element to be of type 'uri'
 >     as defined in XML Schema Part 2 [3]. This means the 'URI' attribute is
 >     a 'URI-Reference' and can have a 'fragment' part.
 >
 >  3. Restrict the semantics of the 'fragment' part of the 'URI-Reference'
 >     to a single case: Only allow the XPointer 'bare name' shortcut as 
 >     defined in [4]. In other words: The content of the former 'IDREF'
attribute
 >     is presented as the fragment part of the 'URI' attribute.
 >
 >  4. All other means of selecting parts of an XML document can be
expressed by
 >     XPath/XPointer transforms.

Gregor, I like this proposal, simple and straight forward. And I think it
works given my understanding of Boyers proposal with respect to serializing
the return (though I'm not sure).

I've tried to rewrite it as a "plug/play" proposal for sections 2.3 [1] and
4.3.3  [2] . You can find the result at [3].

The main chunk of text is:

   The URI attribute identifies a data object using a URI-Reference
   [URI], as specified by RFC2396 [URI]. Note that a null URI (URI="") is
   permitted and identifies the XML document that the reference is
   contained within (i.e., the root element). XML Signature applications
   MUST be able to dereference (obtain the octets associated with) the
   resource identified by a URI (e.g, DOM, an API, network method).

   [URI] permits the specification of a fragment identifier via a
   separating pound symbol '#'. (The meaning of the fragment is defined
   by the resource's MIME type). XML Signature applications MUST support
   the the XPointer 'bare name' [Xptr] shortcut after '#' so as to
   identify IDs within XML documents. The results are serialized as
   specified in section 6.6.3: XPath Filtering. For example,

   URI="http://foo.com/bar.xml"
          Identifies the external XML resource 'http://foo.com/bar.xml'.

   URI="http://foo.com/bar.xml#chapter1"
          Selects the element with ID attribute value 'chapter1' of the
          external XML resource 'http://foo.com/bar.xml'.

   URI='"
          Selects the XML resource containing the signature..

   URI="#chapter1"
          Selecting the element with ID attribute value 'chapter1' of the
          XML resource containing the signature.

   Otherwise, support of other fragment/MIME types (e.g., PDF) or XML
   addressing mechanisms (e.g., [XPath, Xptr]) is OPTIONAL, though we
   RECOMMEND support of XPath. Regarldess, such fragment identification
   and addressing SHOULD be given under Transforms (not as part of the
   URI) so that they can be fully identified and specified. For instance,
   one could reference a fragment of a document that is encoded by using
   the Reference URI to identify the resource, and one Transform to
   specify decoding, and a second to specify an XPath selection.


[1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000208/#sec-o-ObjectReference
[2] http://www.w3.org/TR/2000/WD-xmldsig-core-20000208/#sec-ObjectReference
[3] http://www.w3.org/Signature/2000/02/11-URI-proposal.html



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

Received on Friday, 11 February 2000 14:46:11 UTC