[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Re: XSLT 3.0: Are keys really components that a package should care about?


Subject: Re: [xsl] Re: XSLT 3.0: Are keys really components that a package should care about?
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 17 Nov 2014 09:19:27 -0000

I should add that we could have decided to allow keys to be final, so they can
be referenced in a using package, but not overridden. But I think keys should
probably be regarded as an implementation detail. A package should expose the
functionality of keys using a public function such as

<xsl:function name="get-customer-with-id" as="element(customer)"
visibility="public">
  <xsl:param name="customer-doc" as="document-node(element(customers))"/>
  <xsl:param name="id" as="xs:string"/>
  <xsl:sequence select="key('cust-id-key', $id, $customer-doc)"/>
</xsl:function>

so that the decision to implement this using keys, or maps, or by relying on
the optimizer, becomes an implementation decision that can easily be changed.

Michael Kay
Saxonica
mike@xxxxxxxxxxxx
+44 (0) 118 946 5893




On 17 Nov 2014, at 09:12, Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> You're right about the duplicate mention of modes.
>
> Regarding keys, the introductory sentence of 3.6.3 is factually correct when
it says that the section discusses keys; the last paragraph also states that
keys are different in some ways from other components. They have three
peculiarities: one is that the reference to a key is always dynamic rather
than static (but this is also true of accumulators); the second is that
multiple declarations within a package are cumulative (but this is also true
of attribute sets), and the third is that the visibility is always private.
The latter constraint is one that in principle could be relaxed, but we
considered that allowing key definitions to be overridden would only cause
confusion.
>
> Michael Kay
> Saxonica
> mike@xxxxxxxxxxxx
> +44 (0) 118 946 5893
>
>
>
>
> On 16 Nov 2014, at 23:11, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
>
>> In Section 3.6.3 "Named Components in Packages"
>> (http://www.w3.org/TR/2014/WD-xslt-30-20141002/#named-components ) of
>> the XSLT 3.0 2nd Last Call, we read:
>>
>> "This section discusses the use of named components in packages:
>> specifically functions, named templates, attribute sets, modes,
>> accumulators, keys, modes, and global variables and parameters. Some
>> of the provisions in this section also apply to named modes, but there
>> are differences noted in 3.6.4 Overriding Template Rules from a Used
>> Package. The section is largely concerned with details of the rules
>> that affect references from one component to another by name, whether
>> the components are in the same package or in different packages. The
>> rules are designed to meet a number of requirements:"
>>
>> Besides the mentioning of modes twice in this list (and this also
>> happens at another place of the document), which I hope resulted from
>> duplication and not from omission, I am wondering why keys are in this
>> list of named components at all.
>>
>> As we discover later in the document, an xsl:key always has private
>> visibility -- therefore it cannot be exposed to using packages,
>> because a using-package cannot reference a private component from a
>> used-package.
>>
>> Is this an error... or if not, could someone explain, please?
>>
>> --
>> Cheers,
>> Dimitre Novatchev


Current Thread
Keywords