Initial xsl:record

[johnlumley]

An initial draft of the xsl:record instruction, for discussion

[johnlumley]

The proposed signature uses @xsl:on-duplicates but duplicate handling within the xsl:map should now use @duplicates so the signature needs to be altered. In addition a change to accommodate @xsl:duplicates in the Handling of duplicate keys section needs adding.

[michaelhkay]

I suggest putting xsl:record under a separate section heading from xsl:map, it makes it easier to find the rules applying to each instruction.

There's a need to change the rules for standard attributes such as [xsl:]version -- we can no longer simply say that if the element is in the XSLT namespace, the attribute isn't, and vice versa.

Otherwise looks good.

[michaelhkay]

Needs extensions to the schema for XSLT 4.0.

[ndw]

I can see the motivation for xsl:as and xsl:duplicates, but that's so different from the other instructions that I fear it will cause confusion. I think users are at least as likely to write <xsl:record as="..." to define the record type as they are to write <xsl:record as="..." meaning they want to create an entry with a key of as.

I think I'd prefer it if we just reserved the names as and duplicates for ourselves and said you have to use a sequence constructor to make those entries, if you need them.

[michaelhkay]

so different from the other instructions

Yes, I share this concern. The design is very logical, but also rather unfamiliar. However, I'm not comfortable with reserving attribute names either.

Perhaps an alternative is to put the attributes on a separate element, xsl:record-options, appearing as a child of xsl:record?

[johnlumley]

Yes, I share this concern. The design is very logical, but also rather unfamiliar. However, I'm not comfortable with reserving attribute names either.

I agree - we have a bit of a quandary, with no obvious single-element + options attributes + entry attributes solution possible .

Perhaps an alternative is to put the attributes on a separate element, xsl:record-options, appearing as a child of xsl:record?

This might be a possibility if it only applies to the as|duplicates attributes, which is what I think you're suggesting, but if all entry-generating attributes have to go on an xsl:record-options child (which I suspect you're not advocating) it sort of minimises the conciseness goal. And now we have a special instruction where the options declaration is in a non-intuitive and anomalous position.

Interestingly, in the absence of a contained sequence constructor (which probably will be the vast majority of use cases) we don't need the @duplicates option as there can be no key duplication, so it's only needed where there is a sequence constructor, which already reduces the conciseness.

[ndw]

Is there a compelling reason not to allow QName keys:

<xsl:record xmlns:e="http://example.com" e:foo="Spoon!"/>

[michaelhkay]

Is there a compelling reason not to allow QName keys:

Mainly consistency with record type declarations. You can't define a record type that expects non-string keys. That in turn is consistent with JSON objects.

[ndw]

#HEADDESK, of course. Apologies for the noise, I was thinking of a map constructor.