Re: ACTION 176: Text for 1.1 on use of Transforms with RetrievalMethod

(1) Maybe change this proposal text from:
"A future version of this specification may deprecate or entirely  
remove this feature in favor of a simpler, less general referencing  
model more suitable for the specific purpose of key references. In the  
meantime,use of this feature may lead to interoperability issues."

to

"Use of transforms should be limited to the minimum case of extracting  
a single included element from KeyInfo."

?

(2) Perhaps we can add an id attribute to KeyInfo content to avoid the  
need for a transform?

Should we include an errata in 1.1 to add id attributes to KeyInfo  
children and remove transforms from RetrievalMethod?

regards, Frederick

Frederick Hirsch
Nokia



On Jan 23, 2009, at 11:31 PM, ext Scott Cantor wrote:

>
> I believe the intent here was to signal that using Transforms with
> RetrievalMethod was a bad idea and that the feature would be altered  
> in the
> future. The action speaks to "deprecation" in 2.0, but I think we'd be
> changing the syntax or feature so much that it would just be a non- 
> option,
> not deprecated.
>
> This proposal also includes some explanatory text about how the spec  
> ends up
> defining RetrievalMethod for the built-in types, which seems to be a  
> point
> of confusion.
>
> Suggested new text in section 4.4.3 before the schema fragment:
>
> ----
>
> The implication of these requirements is that when referencing one  
> of the
> defined KeyInfo types within the same document, or some remote  
> documents, at
> least one Transform is required to turn an ID-based reference to a  
> KeyInfo
> element into a child element located inside it. This is due to the  
> lack of
> an XML ID attribute on the defined KeyInfo types.
>
> Note that while this syntax and dereferencing behavior allows for  
> the use of
> Transform child elements, this feature is considered risky, and is  
> overly
> complex and general for the use cases for which RetrievalMethod was
> intended. A future version of this specification may deprecate or  
> entirely
> remove this feature in favor of a simpler, less general referencing  
> model
> more suitable for the specific purpose of key references. In the  
> meantime,
> use of this feature may lead to interoperability issues.
>
> ----
>
> -- Scott
>
>
>

Received on Monday, 26 January 2009 16:12:34 UTC