RE: XPath, XPointer & Re: XSLT and XSL

Hi Mark,

Yes I see how that could be ambiguous.

In the previous email, you said you agree with Sharon Adler, who Don quoted
as saying that using XPath/XPointer for digital signature was meaningless.
That was what I disagreed with in saying that of course we have always
expected a barename xpointer to yield text that we could send to a digest.

For some time, many have asked 'Can't we just have
Location="someURL#someFragment" to indicate what must be signed?' The
implication is that people just want to identify an element by ID and sign
the text of the indicated element.  This is identical to my expectation of a
barename XPointer.  Getting the full text of the element is, to me,
equivalent to doing a pointer dereference.

Honestly, I don't think the XPath/XPointer people saw it as needing to be
specified.  They were only trying to identify a set of nodes appearing in
the parse tree.  If someone wants to subsequently write those out, that is
such a well-known operation that there was no need spelling out for us that
we could write it out.  Nor was there a need for them to restrict people
from using the nodes in a different order than they appear in the original
document.  This allows XSLT to decide that a different order is appropriate
(as defined by the transform), but that doesn't mean the rest of us should
be locked into an 'unordered' land.

As to whether our spec uses natural language or an XSLT to say "apply the
XPath and generate the result in document order" is, to me, a trivial point.
However, to say it in XSLT requires that XSLT can generate results which are
not well-formed XML since the result of an XPath or XPointer can be a region
of a document that has no root element.  Actually, my own preference is that
the tags of all ancestors of a document region be included in any message so
you can recover the namespaces and the charset encodings, but I understand
that others have a different preference, so we need to account for that.

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: Friday, October 29, 1999 12:32 PM
To: 'John Boyer '; 'w3c-ietf-xmldsig@w3.org'
Subject: RE: XPath, XPointer & Re: XSLT and XSL


Hi John,

I'm unclear as to what you are disagreeing with.  I talked about three
options:

1)  Just define an XSLT transform [my preference]

2)  Define an XPath transform, but define it such that you can trivially
convert it to an XSLT transform [not as good as 1), but I could be
convinced]

3)  Define an XPath transform in some other fashion [I really don't like
this option]

To clarify 2), I mean that you can pull the XPath out of the XPath transform
and plug it into a fixed boilerplate XSLT transform and achieve the same
effect.  Said boilerplate to be given in the spec.

Now, the difference between 2) and 3) may well be just a matter of how we
word the specification.  That's ok.

Now to motivate option 1).

The argument for having a transform that is "just" XPath is that it will be
much simpler to implement XPath than to implement XSLT.  But I don't expect
anybody to be implementing XPath or XSLT just for digital signatures.  I
expect in the (vast?) majority of cases people will be using a third-party
XSL library, even just for XPath, since (I get the impression) XSL is in
large part the motivation for XPath.  Most implementations of XPointer will
be part of an XSL implementation.

I admit that much of the preceding paragraph is merely my personal
impressions; I would like to hear what other people think.  I think that
many of the people who object to extra "weight" in the spec won't be using
XPath or XSLT, and so for this issue the "weight" argument carries less,
umm, weight.

The argument against having an XPath transform has been well represented.
XPath doesn't yield an octet-stream.  Now, we could define a conversion
mechanism but I fear we'll be unnecessarily opening a big can of worms.
Even if we are able to accurately and unambiguously define such a beast,
implementing the algorithm becomes a "small" part of implementing XML
digital signatures.  I fear that even if we get the algorithm right, people
who implement digital signatures won't.  I know, you insist that it is
simple and straightforward, but I remain uneasy.  With XSLT people can just
grab an implementation.

So, I am arguing for 1), but I would be much more easily convinced for an
XPath transform if we could do 2) instead of 3).  Implementors that have
XSLT available can just trivially make the XPath transform into an XSLT
transform instead of implementing another algorithm.

-Mark Bartel
JetForm

-----Original Message-----
From: John Boyer
To: Mark Bartel; 'IETF/W3C XML-DSig WG '
Sent: 10/28/99 1:38 PM
Subject: RE: XPath, XPointer & Re: XSLT and XSL

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
To: 'IETF/W3C XML-DSig WG '
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
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 Friday, 29 October 1999 16:45:10 UTC