ISSUE-67: Revise XSLT transform; it's currently octet-stream to node-set.

norm...XProc pipeline would output nodeset...would not make sense to have c14n...as that would output octet stream

<klanz2> All this XML == XML' ? Is allover the place in XML and causes so many headaches ... http://www.w3.org/TR/xslt#strip

<klanz2> and many more places and so on ...

frederick...these two requirements are linked...looks like must do both

<fhirsch3> removing the requirement to allow transforms to move from octet stream to nodeset and back as well as enabling c14n only has pre-hash signing step could greatly improve performance, simplification

<fhirsch3> can not do both!

<tlr> Konrad is unfortunately right about XSLT

<tlr> http://www.w3.org/TR/xmldsig-core/#sec-XSLT

<tlr> ISSUE: Revise XSLT transform; it's currently octet-stream to node-set.

<trackbot> Created ISSUE-67 - Revise XSLT transform; it's currently octet-stream to node-set. ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/67/edit .

frederick...not arguing against "sign-what-you-see" but did we make this more complicated than what was needed?

bal...whole reason for xform chains was for document subsets

<klanz2> Document subsets is XPointer

frederick...do we really need the transform chain mechanism?

<klanz2> Imagine Database A and Database B ....

bal...do you need to have subselection of URI-addressable parts?

<klanz2> and you send a detached signature from A to B ...

<klanz2> and the transforms dereference data from those data bases and the signature shall verify without actually transferring the data#

<klanz2> so would could make this a NON use case

<klanz2> but currently these things are used ...

tlr...XSLT transform requirement will constrain us...unless dealt with somehow

Subtopic: XProc futures

norm...going to CR the end of this week

norm...may get uptake early next year

norm...if case that dsig is atomic operation with few options, could argue that is part of XProc

norm...seems more complicated, would be compound steps, more than can be added to XProc

rdmiller...some work has already gone into this dsig+Xproc step/steps, will share later

<klanz2> is an XProc chain delivering the same output if executed on different processors ...

<klanz2> I mean if you stuck it into a digest will it deliver the same digest

<klanz2> maybe that is an interesting idea and then all other specs would have to assure that their output is canonical to some extend ..

konrad...if security is of concern to authors of XML apps, should have canonical form

tlr...most specs tell how to parse, not how to serialize, canonicalize

<klanz2> Security is inconvenient and costly, but is necessary to assure long term survival of any technology ...