RE: XPath, XPointer & Re: XSLT and XSL

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

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?

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.

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.

Thanks,
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
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 Monday, 25 October 1999 15:22:28 UTC