ACTION-127: Tade-offs between different extensibility mechanisms

I propose adding the following text above section 2.1.2, under Best  
Practice 3 ("Consider avoiding XSLT Transforms"):

> Instead of using the XML Signature XSLT transform, deployments can  
> define a named transform of their own, by simply coining a URI in  
> their own domain that can be used as the Algorithm.  How that  
> transform is implemented is then out of scope for the signature  
> protocol -- a named transform can very well be built in XSLT.

> In deciding whether to pursue this avenue - instead of embedding  
> XSLT transforms in-line with the signature - considerations will  
> involve the ease of deployment and flexibility:  When the XSLT  
> transform mechanism is used to transmit transforms inline, then the  
> signer can change the untransformed data format and the  
> transformation without having to synchronize with the verifier, as  
> long as the result of the transformation meets the verifier's  
> assumptions.  In some use cases, this flexibility may prove  
> valuable.  Deployment of a named transform will require that signer,  
> verifier, and any intermediaries that need to process the transform  
> output, be aware of the identifier and the meaning of that transform.

I don't know if there's much more we'd want to say about this; input  
welcome.

FWIW, I consider my action item closed.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Monday, 17 August 2009 11:33:59 UTC