RE: Action-565: Visible Utilization in XPath

> *Approach #3: prohibit QNames in XPath*
> 
> Instead of using QNames in XPath, we force the XPath expressions not to
> contain any QNames. For namespace-free documents this means no change,
> for namespace-aware documents this requires sth. like putting
> "/*[local-name()='Body' and
> namespace-uri()='http://www.w3.org/2003/05/soap-envelope']" instead of
> "/soap:Body".
> 
> Drawbacks:
> High threat of developers to screw it up.

This is the one that I think should be recommended but not required. QNames
in content are simply bad things. We know that now, and the remanining uses
of them are from specs that predate that knowledge. Which is life. But where
there are alternatives that allow the same functionality without using them,
we would be crazy IMHO not to bless those approaches as being better for use
with signatures.

Developers will screw up anything and everything, and that's also just life.
That shouldn't prevent us from documenting workarounds that actually *solve*
this problem. It's quite rare in these cases for such solutions to actually
exist at all.

> *Approach #4: listing used QNames explicitly*
> 
> On signature generation, when defining the XPath expressions for the
> signature reference, this approach requires an explicit statement
> listing all QNames used in the XPath as part of its definition.
> 
> Example:
> 
> <IncludedXPath QNames="soap:Body
> my:Node">//soap:Body/my:Node</IncludedXPath>
> 
> Drawbacks:
> Requires changes to XML Signature 2.0 syntax, threat of forgetting
> used/adding unused QNames.
> Puts additional tasks to the signature generator.
> Somewhat redundant information.

I think this one is also worth considering, because changing the syntax is
not a drawback at this point (we're in draft) and because it's likely that
the creator of the XPath expression is in a good position to know what
QNames are actually being used, seems to me.

-- Scott

Received on Tuesday, 11 May 2010 15:26:33 UTC