Re: fragment identifier as uri? (IDREF baggage)

Hi Dan,

From:  Dan Connolly <connolly@w3.org>
Resent-Date:  Mon, 31 Jan 2000 23:32:12 -0500 (EST)
Resent-Message-Id:  <200002010432.XAA08727@www19.w3.org>
Message-ID:  <38966101.1927636A@w3.org>
Date:  Mon, 31 Jan 2000 22:28:49 -0600
Organization:  World Wide Web Consortium (http://www.w3.org/)
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
CC:  IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>,
            "C. M. Sperberg-McQueen" <cmsmcq@acm.org>,
            "Henry S. Thompson" <ht@cogsci.ed.ac.uk>,
            Tim Berners-Lee <timbl@w3.org>
References:  <200002010241.VAA32070@torque.pothole.com>

>"Donald E. Eastlake 3rd" wrote:
>> 
>> I've been thining about this some more and believe we should just go
>> with what all normal people think of as a URI.
>
>[and there was much rejoicing!]
>
>[...]
>
>> I don't see the non-validating parser / absence of a DTD as that much
>> of a problem as signature aware applications should, in effect, have
>> the XMLDSIG DTD built in and so can recognize our IDs in our elemnts,
>> including the Object elment, for example, which can be used to wrap an
>> optionally encoded data item anywhere in the document which contains
>> the Signature element, if the application is designed that way.
>
>Er.. you mean:
>	<!DOCTYPE Signature SYSTEM "http://www.w3.org/2000/...signature.dtd">
>	<Signature>
>		...
>	<Object>
>	23lk4j23j423... base64/quoted-printable/&#nnn; encoded
>	stuff ... oiu234oi2u34o23
>	</Object>
>	</Signature>
>?

I believe there will be very few naked <Signature> documents.  Almost
all real uses of Signature will be inside forms or protocol messages
or whatever.  But that's not relavent to this point.

When I say the signature spplication can find our IDs in our elements, I
mean you could have

<!DOCTYPE ... whatever ...>
<rootelement>
	... lots o junk ...
	<Signature xmlns="http://www.w3.org/2000/...signature...">
		<..various signature guts..>
		<Object ID="item1" encoding="...">
			...stuff1...
		</Object>
	</Signature>
	...yet more junk...
	<Object xmlns="http://www.w3.org/2000/...signature..."
			ID="item2" ...>
		...stuff2...
	</Object>
</rootelement>

and certainly any reasonable implementation of XML digital signatures
should be able to find stuff1 from a reference to ID item1 from inside
"signature guts" and that it is perfectly reasonable for an XML
digital sig implemention to be able to find stuff2 from a reference to
ID item2 from inside signature guts.  This is true whether or not the
parser which parses rootelement is validating or has access to either
the rootelement or Signature DTDs.  If it, for example, have access to
the whole doucment DOM tree, it can, if necessary, grovel over it
looking for elements in the dsig namespace where it knows what
attribute is the ID.

>Surely you're not going to prevent the straightfoward idiom where
>DSIG markup and application markup are nested ala:
>
>	<Signature xmlns="http://www.w3.org/...signature">
>		...
>	<Object>
>		<myTag xmlns="http://example.com/mystuff">
>			...<myOtherThing label='xyz'/>..</myTag>
>	</Object>
>	</Signature>

No, I would expect dsig to almost always be inside application markup
and application markup to frequently occur inside dsig.

>This is the case where it's infeasible to dereference IDREFs ... when
>you *didn't* write the DTD for myTag/myOtherThing. How is DSIG software
>going to know that the label attribute of the myOtherThing element
>has type ID? It has to read the DTD. And heck... it's
>a fairly hairy challenge just to come up with a DTD that combines
>the DSIG DTD with a DTD for myTag. But even in this case,
>it's straighfoward to write an #xptr(...) expression for
>"the element whose label attribute has value 'xyz'".

In general it can't, without the DTD.  And I'm not eliminating the
possibility of using XPath or the like.  I'm just saying that if the
applicaion is willing to reference the IDs that dsig provides on the
dsig defined elements, then for dsig purposes it does not seem
necessary to have the application DTD available.  My argument is that
IDREFs may therefore be more useful than it seems at first glance,
which is independent of whether you require a separate IDREF= usage or
permit URI="#token".

>> On the other hand, I don't give much weight to the argument against an
>> IDREF attribute because it is so limited compared with a URI when we
>> provide the URI attribute as an alternative.
>
>It's the usual argument for simplicity... the added code complexity
>isn't much in this case, but the added bloat in the spec that reviewers
>have to wade thru, extra test cases, tutorial material, ... adds up.

Yes, I agree.  A single URI-ref is simpler.

>-- 
>Dan Connolly
>tel:+1-512-310-2971
>http://www.w3.org/People/Connolly/

Donald
===================================================================
 Donald E. Eastlake 3rd                    dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1            lde008@noah.dma.isg.mot.com
 Carmel, NY 10512 USA     +1 914-276-2668(h)    +1 508-261-5434(w)

Received on Tuesday, 1 February 2000 08:35:38 UTC