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
JetForm

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
To: IETF/W3C XML-DSig WG
Sent: 10/27/99 12:54 PM
Subject: Re: XPath, XPointer & Re: XSLT and XSL 

Hi,

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
Message-ID:  <NDBBLAOMJKOFPMBCHJOIOEMOCBAA.jboyer@uwi.com>
In-reply-to:  <199910251330.JAA03417@torque.pothole.com>

>Hi Don,
>
><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.
></Don>
>
>Yes, I thought we'd been through this already and that the decision was
that
>we would define our use of XPath or XPointer as identifying a node-set
that
>would be rendered to a message in document order.  See Section 5.6.3 of
the
>core syntax draft[1], particularly #3 in the list appearing in that
section.
>
>[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
of
>what we needed to effectively achieve document closure. The fact that
it is
>missing one necessary piece does not make the whole effort
"meaningless".
>It means that the effort is MOSTLY meaningful, but that a small
additional
>effort is required to say that that applications (such as dsig) will
use
>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
have
>been the intent of XPointer to indicate a single element, but it
doesn't
>come across in the current specs since XPath is a subset of XPointer,
since
>there seems to be spanning capabilities, and since we really don't know
what
>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
want
>is essentially to dereference that pointer.  Where in the XPath or
XPointer
>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
order
>is even the best default order for scenarios outside of the needs of
digital
>signatures.  I can't figure out why Xpath says node sets are unordered
>(except for mathematical cleanliness in use of the word 'set', which
seems
>pedantic at best), but I think that the lack of a good reason should
not
>deter us from adding that extra bit of effort to define document order
so
>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.

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

Thanks,
Donald

>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Donald E. Eastlake
>3rd
>Sent: Monday, October 25, 1999 6:30 AM
>To: IETF/W3C XML-DSig WG
>Subject: XPath, XPointer & Re: XSLT and XSL
>
>
>
>Thanks,
>Donald
>
>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:  <3.0.5.32.19991021170445.00934490@localhost>
>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>
>In-Reply-To:  <NDBBLAOMJKOFPMBCHJOIOELNCBAA.jboyer@uwi.com>
>References:  <3.0.5.32.19991021142506.00a40ae0@localhost>
>
>>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,
though
>> >the spec is confusing about it.
>> >
>> ><John>
>> >I got the impression that XSL could give you the final HTML that a
person
>> >would look at.  I also could not tell on a single 14 hour Saturday
which
>> >part of this could not be done by the XSLT, but that's at least
partly
>> >because the combined spec length is over 350 pages.  I thought it
best
>for
>> >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,
this
>was
>> >in keeping with the motto "What you see is what you sign" which I
think
>was
>> >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
>chosen
>> >XSLT. Depending on how I read 1 and 2, you either did or did not
choose
>>XSL.
>> >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
formatting.
>>
>>_________________________________________________________
>>Joseph Reagle Jr.
>>Policy Analyst           mailto:reagle@w3.org
>>XML-Signature Co-Chair   http://w3.org/People/Reagle/
>

Received on Wednesday, 27 October 1999 13:28:25 UTC