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 12:54:33 UTC