W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

RE: XPath, XPointer & Re: XSLT and XSL

From: John Boyer <jboyer@uwi.com>
Date: Thu, 28 Oct 1999 10:38:25 -0700
To: "Mark Bartel" <mbartel@thistle.ca>, "'IETF/W3C XML-DSig WG '" <w3c-ietf-xmldsig@w3.org>
Hi Mark,

The reason I don't agree is because it is at odds with the vociferously
defended point about needing XPointer to do precisely what is suggested in
5.6.3 and 5.6.4. In order to perform the simple ID fragment concept,  the
result of a Location plus a barename XPointer needs to be a text message
that can be sent to a digest algorithm.

In general, the advantage to XPath and XPointer transformations is that they
allow a certain amount of sophistication without needing to incorporate full
blown XSLT. XPath is quite sufficient for filtering a document to precisely
omit unwanted pieces without needing to change what is kept. For example,
XPath is the smallest sufficient standard that could completely cover the
needs of XFDL, yet even XPath is more than needed in a number of ways.

Thus, XPath, XPointer, and XSLT were "RECOMMENDED".

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

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Mark Bartel
Sent: Wednesday, October 27, 1999 10:28 AM
Subject: RE: XPath, XPointer & Re: XSLT and XSL

I agree with Sharon.  I am very uncomfortable with the idea of defining our
own XPath-to-octet-stream algorithm.  I would much rather we just use
straight XSLT.

If we are going to specify our own XPath-to-octet-stream algorithm, I would
be least uncomfortable if we defined it in terms of XSLT.  In other words,
our algorithm is the one the produces the same results as plugging the
specified XPath into a given, constant chunk of XSLT.  It's been a long
while since I looked at XSLT but I'm assuming this is feasible.  Besides
adding clarity, this allows people who have XSLT available to trivially
perform the XPath-to-octet-stream algorithm.

But as I said, I'd prefer we just use XSLT directly.

-Mark Bartel

PS  I also agree with Don in that I think many other people will have
Sharon's reaction.  I think the intuitiveness of the XSLT approach is a
significant advantage.

-----Original Message-----
From: Donald E. Eastlake 3rd
Sent: 10/27/99 12:54 PM
Subject: Re: XPath, XPointer & Re: XSLT and XSL


From:  "John Boyer" <jboyer@uwi.com>
Resent-Date:  Mon, 25 Oct 1999 15:22:33 -0400 (EDT)
Resent-Message-Id:  <199910251922.PAA12388@www19.w3.org>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Date:  Mon, 25 Oct 1999 12:22:11 -0700
In-reply-to:  <199910251330.JAA03417@torque.pothole.com>

>Hi Don,
>I spent some length of last week in the office of Sharon Adler,
>co-chair of the XSL WG, discussing this.  It's certainly her opinion
>that trying to use XPath or XPointer as currently defined as a filter
>is meaningless.  XPointer is just intended to give you a pointer into
>an XML document.  It doesn't yield XML.  XPath just gives you an
>unordered node set.  It doesn't yield XML.  XSLT, on the other hand,
>can give you XML, although even conformant XSLT processors are not
>required to be able to output XML.  XSLT has provisions via the
>"output" element for specifying the additional parameters you would
>need to know to generate XML.  Of course, there is nothing stopping us
>from defining dsigXPointer and/or dsigXPath which do yield XML.
>Yes, I thought we'd been through this already and that the decision was
>we would define our use of XPath or XPointer as identifying a node-set
>would be rendered to a message in document order.  See Section 5.6.3 of
>core syntax draft[1], particularly #3 in the list appearing in that
>[1] http://www.w3.org/TR/1999/WD-xmldsig-core-19991022.html
>Thus, I would disagree with Sharon Adler's characterization of this as
>meaningless.  As currently defined, the XPath spec contains nearly all
>what we needed to effectively achieve document closure. The fact that
it is
>missing one necessary piece does not make the whole effort
>It means that the effort is MOSTLY meaningful, but that a small
>effort is required to say that that applications (such as dsig) will
>document order to

Well, Sharon Adler didn't look at the core syntax draft.  I'm
wondering if we should call it simply "XPath" if it yields a different
type from XPath...

>A) render a message from the unordered node-set of an XPath
>B) dereference the "pointer into an XML document"
>I don't look at XPath and XPointer as being terribly different.  It may
>been the intent of XPointer to indicate a single element, but it
>come across in the current specs since XPath is a subset of XPointer,
>there seems to be spanning capabilities, and since we really don't know
>is meant by a single element (the element plus its attributes, or the
>element plus its descendant elements, or both, or...).
>No matter how you look at it, the XPath or XPointer is essentially a
>'pointer' to a collection of nodes in a document, and the operation we
>is essentially to dereference that pointer.  Where in the XPath or
>specifications does it say that applications should not consider the
>possibility of doing a pointer dereference to get the actual data?

While they don't say that and provide functions for retrieving data
from a node, they don't provide a function to produce XML.

>Finally, it is trivially easy to come up with the fact that document
>is even the best default order for scenarios outside of the needs of
>signatures.  I can't figure out why Xpath says node sets are unordered
>(except for mathematical cleanliness in use of the word 'set', which
>pedantic at best), but I think that the lack of a good reason should
>deter us from adding that extra bit of effort to define document order
>that we can do a simple pointer dereference.

I suspect they are also trying not to constrain implementations.

>This is why I very much liked your concall suggestion to do define the
>difference between what XPath/XPointer offered and what we needed, and
why I
>don't understand why this is still an issue.

If there is a consensus that the additional material in 5.6.3 and
5.6.4 is adequate (perhaps equivalent to some specific XSLT
template(s) and specific XSLT output element), then I guess there
isn't an issue.  However, Sharon Adler's reaction may be typical of
the reaction of some others in the XML standards area.

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


>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Donald E. Eastlake
>Sent: Monday, October 25, 1999 6:30 AM
>Subject: XPath, XPointer & Re: XSLT and XSL
>From:  "Joseph M. Reagle Jr." <reagle@w3.org>
>Resent-Date:  Thu, 21 Oct 1999 17:04:54 -0400 (EDT)
>Resent-Message-Id:  <199910212104.RAA21721@www19.w3.org>
>Message-Id:  <>
>Date:  Thu, 21 Oct 1999 17:04:45 -0400
>To:  "John Boyer" <jboyer@uwi.com>
>Cc:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
>References:  <>
>>At 12:51 99/10/21 -0700, John Boyer wrote:
>>Reagle wrote:
>> >3. I don't think we should have an XSL and XSLT. One or the other,
>> >the spec is confusing about it.
>> >
>> ><John>
>> >I got the impression that XSL could give you the final HTML that a
>> >would look at.  I also could not tell on a single 14 hour Saturday
>> >part of this could not be done by the XSLT, but that's at least
>> >because the combined spec length is over 350 pages.  I thought it
>> >now to allow a full stylesheet to be put in and let it modify the
data to
>> >the point where it represents what the user actually sees.  Again,
>> >in keeping with the motto "What you see is what you sign" which I
>> >reiterated in that email from Don.
>> ></John>
>> >
>> >1. XSLT is a subset of XSL that specifies the transformation
methods, XSL
>> >also includes the formatting object syntax.
>> >2. XSL is merely one sort of XSLT used for formatting.
>> >
>> >I opted for #2.
>> >
>> ><John>It is not clear what #2 means.  In the spec, you seem to have
>> >XSLT. Depending on how I read 1 and 2, you either did or did not
>> >Is there some newer draft we don't have?
>> ></John>
>>By that I mean we have a XSLT blob. One particular type of XSLT is to
>>transform a source document into a target document with XSL
>>Joseph Reagle Jr.
>>Policy Analyst           mailto:reagle@w3.org
>>XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Thursday, 28 October 1999 13:38:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC