Re: Proposed processing model for Reference and Transforms

Hi John,

I'm afraid that I got a bit confused earlier; I was reading some
bits of your proposal out of context. Or I wasn't reading them at
all. Or something.

But my problem boils down to the following:

  <Reference URI='#foo'>
  <XPath>...</XPath>
  <Bar Id='foo'>
    <Baz>
      <Bar>
        <Baz />
      </Bar>
    </Baz>
  </Bar>

How can my XPath easily identify the Baz child of only the
referenced Bar and not those of its deeper progeny, without
using IDs or such? More generally, how can it determine what was
the actual element identified by the reference? In particular,
a signature may have an absent URI and may be presented with
an arbitrary node subtree from the parent document. How does
it identify the root of this subtree?

I could probably use an XPointer range but I'd rather not bring
advanced XPointer into my solution; pure XPath is a lot easier.

Essentially, the new model causes problems in writing XPaths that
desire knowledge of the context of an input node set. The old
XPath '/dsig:Object/text()' doesn't fit into the new model.

If I impose a C14N step between the XPointer and my XPath I can
use '/', but I want to eliminate such C14N steps.

There are *no* implementation problems with your proposed model;
using an off-the-shelf XPath processor, an implementation boils
down to just a couple of lines. It is purely a functional issue:
I'm not terribly enamoured of the XPaths that I have ended up
writing.

Given that XSLT allows us to effectively perform per-element
XPath processing, are we losing a useful capability by changing
our XPath processing to do the same?

I actually don't have strong opinions on this matter.

The alternative is to define that the XPath transform is applied
to a "virtual document" consisting of just the node set, rooted
at the highest element of the node set. XSLT too - no C14N step
would be mandatory. If the node set isn't a tree, that's an
error.

A simple implementation would be to actually perform the C14N,
preserving here() in an application-specific manner (easy). An
efficient implementation would use a specialized XPath
processor.

To summarize the different types of XPath that we would get:

<XPath>[count (ancestor-or-self | id('foo')/Baz) =
        count (ancestor-or-self)]</XPath>
  or...
<XPath>/Baz//. /Baz//@* /Baz//namespace::*</XPath>

Both are ugly, and this is clearly a trivialized (and probably
biased) case. I just don't like id('foo') in the XPath and I
don't see how to get around it, and I always end up doing set
counting operations. I am probably blinkered, there probably
is a way.

Merlin

r/jboyer@PureEdge.com/2000.08.29/11:33:43

> <!-- comments elided pending digestion -->

Received on Wednesday, 30 August 2000 11:53:47 UTC