Re: A few items cherry-picked from comment #54 - proposal for p:label-elements

A sound proposal.

About the context node:
Is there any reason why this won't be actually "any XPath" expression on 
top of the input document rather than the context node?
This would limit the applicable use cases to only trivial ones. 
Optimization wishes would still be valid, the processor can determine 
whether this is context node, document or none of them in the same way.

About the replacing the value if present:
Can this be configurable option in form of true/false?

Nikolai

ext Alex Milowski wrote:
> On 1/25/08, Norman Walsh <ndw@nwalsh.com> wrote:
>   
>> We defered an issue (#54) at the f2f but then failed to return to it.
>>
>> 3. Should we add a scheme to p:label-elements that generates an ID by
>>    evaluating an XPath expression?
>>
>>     
>
> Here is a proposal based on our discussion on the call:
>
>    * drop the 'prefix', 'suffix', and 'scheme' options.
>    * add a new option called 'label' which is an XPath expression
>    * If the 'label' option is not present, the expression
> "concat('_',$p:index)" is used.
>
> The text would be:
>
>
> The value of the attribute option must be a QName.
>
> The value of the match option must be an XSLTMatchPattern. It is a
> dynamic error (err:XC0024) if that expression matches anything other
> than element nodes.
>
> This step operates by generating attribute labels for each element
> matched.  For every matched element, the expression is evaluated with
> the context node set to the matched element.  An attribute is added to
> the matched element using the attribute
> name is specified the attribute option and the string value of result
> of evaluating the
> expression.  If the attribute already exists on the matched element,
> the value is
> replaced with the string value of the expression evaluation result.
>
> An implementation must bind the variable 'p:index'  in the static
> context of each evaluation to the position of the element in the
> sequence  of matched elements.  In
> other words, the first element (in document order) matched gets the
> label "1", the
> second gets the label "2", the third, "3", etc.
>
> The result of the p:label-elements step is the input document with the
> attribute
> labels associated with matched elements.  All other non-matching content
> remains the same.
>
>
> We may optionally add a note that says something like:
>
> An implementation may detect that the XPath expression does not require the
> context node or apply other such optimizations that do not require
> caching of the
> whole document.
>
>
> I had to remove the statement about unique values because an expression
> like "'string'" would evaluation to the same value for every element.
>
> Also, we should decide whether p:index is a string or number.
>
>

Received on Thursday, 7 February 2008 10:18:32 UTC