Re: XSLT lingual extensions?

Nice! Michael, thanks for pointing to the *call template instruction*.

Seems it fits almost perfectly. Only controversial part is the restrictions
purpose.

1. namespace for extension instruction. Can it belong to one of
registered/default?
In my case it belongs to the external engine ( browser DOM ) which is
*html:* prefix or no prefix at all. The DOM parser is a browser.  In my
proposal the instruction meant to replace existing construct with its own
namespace to XSLT template call. According to XSLT 4.0, "this namespace
must be designated as an extension element namespace" . Sounds like default
or http: namespace is not supported 😔?

2. " the names of its attributes (other than standard attributes
<https://qt4cg.org/specifications/xslt-40/Overview.html#dt-standard-attributes>)
are matched against the names of the template's parameters."
In HTML the strict schema is not velcome and developers are used to put a
bunch of supplemental info into DOM. Hence the strict match requirement
would produce XSLT import errors?

IMO the purpose of integration into existing DOM engine should lift this
restriction and even more: let the access to the free style attributes from
template itself to either be passed through as is or transformed.


On Mon, Jan 2, 2023 at 2:18 PM Michael Kay <mike@saxonica.com> wrote:

> This seems to have a high level of overlap with the proposed XSLT 4.0
> extension allowing extension instructions to invoke named templates:
>
>
> https://qt4cg.org/specifications/xslt-40/Overview.html#invoking-templates-with-extension-instructions
>
> Michael Kay
> Saxonica
>
>
>
> On 2 Jan 2023, at 20:23, Sasha Firsov <suns@firsov.net> wrote:
>
> Thinking of macro in XSLT...
>
> In many programming languages the capability of extending lingual
> constructs been found not just a useful but even not-separable part of the
> language itself.  For example, the macros in C are an essential part of the
> standard and almost any shared code.
>
> XSLT itself has some capability to extend its own functionality inside of
> XPath. Which is powerful for data and string utilities but does not give
> much on the integration of markup itself.
>
> During  Declarative Custom Element proposal preparation I faced the
> challenge of TEMPLATE tag syntax into XSLT translation. The SLOT tag can be
> easily expressed via <value-of  select=...
>
> function slot2xsl( s )
> {
>     const v = document.createElementNS( XSL_NS_URL, 'value-of' );
>     v.setAttribute( 'select', `//*[@slot="${ s.name }"]` );
>     s.parentNode.replaceChild( v, s );
> }
>
> While for POC(link
> <https://unpkg.com/@epa-wg/custom-element@0.0/index.html>) it is OK kind
> of XSLT pre-processing on JS level, the XSLT by itself is the best for such
> kind of XSLT-to-XSLT transformation. As optimization, the XSLT pipeline
> could be set but it means extra step and disconnection between the HTML
> template source and final transformation. The less steps in the pipeline,
> the better DX/DE( Developer Experience/Developer Efficiency).
>
> Hence proposing the macro definition for XSLT:
> defined construct would be transformed into XSLT one and treated as inline
> XSLT.
>
> <slot name="slot1"> 😃</slot>
>
> translated into
>
> <xsl:value-of select='//*[@slot="slot1"]'/>
>
> I guess there is no need for new XSLT syntax to support macro definition,
> the usual
>
> <xsl:template match="slot">
>    <template:value-of><xsl:attribute name="select"      >//*[@slot="<xsl:value-of select="@name">"]</xsl:attribute></template:value-of>
>
> would be sufficient with one extra exception on the pipe priority so it
> would run during the XSLT load ( and take XSLT itself as data) instead of
> the transformation phase.
>
> 🤔 How to
> * present the XSLT load vs transformation phase
> * present the output XSLT ( via template: namespace?)
>
> -s
>
>
>
>