OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Community Group for QT4 specs

The xsl:merge instruction in 3.0 was designed to be able to handle this kind of use case - have you considered it?

Michael Kay

On 29 Nov 2020, at 03:17, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

I would like to see some support for processing synchronized documents. I mean where you process nodes in document S (slave) by looking at what "corresponding" nodes in document M (master or model) are, BUT coping with gaps in both (where M does not have corresponding nodes, and where M has nodes that with no correspondence in S).  

It is something like this: map each node in S & M to some signature (a XPath with key), then for each S or gap-in-S process corresponding [S,M] pairs with the same key or handle gaps where a key does not have a partner.

Traversing two identical trees is easy in XSLT, but it falls down when there are gaps, and I cannot help but wondering if there is some primitive missing.

The use case here is end-to-end inspection of complex multi-stage multi-inout/output transformation pipelines, or even AB unit tests. So not QA but QC, validation but verification: comparison of outputs against inputs rather than schemas.  Testing conservation of document variants rather than testing invariants, if you like.

Strawman:  It could be something like this:

<xsl:model href=""/>

     match="section[@type='group1']/heading"  priority="2"
     model-match="group1/title"  model-priority="3"

     model-key="count(preceding::group1)" >

   <xsl:when test="model-current() != node()">
        .. no corresponding model match 

   <xsl:if test="current() != node()  or current()=()" >
       ... missing item that model has item for
      <xsl:variable name="INDEX" select="model-key()/>
       <xsl:push mode="second-pass" 
                select="//section[@type='group1'][count(preceding::section[@type='group1'])= $INDEX - 1]" 
              <xsl:call-function name="handle-missed-group1">
                   <xsl:with-param name="model" select="model-current()"/>

      ... normal processing

So this is 
0) an element xsl:model to set the model document and enable these features.

1) an element xsl:push (or xsl:defer or xsl:future or xsl:thunk or whatever) which queues a function to be run after/before some context is matched in a particular mode  that must be explicitly apply-templated sometime. 

2) xsl:template is extended to also match some model with a corresponding key, or gaps in either. 

3) a function model-current() is added to retrieve the model and context. A function model-key() retrieves the model key value.

Or is there some way to do this already, without being in a some elaborate mess?


On Sat, 28 Nov. 2020, 04:18 Michael Kay, <mike@saxonica.com> wrote:
I have established a W3C community group to work on extensions to the XSLT/XPath/XQuery 3.x specs, and invite participation.

There have been initial proposals on the EXPath-ng forum, in my XML Prague 2020 paper, and more recently I have published some proposals in W3C spec format.

I've forked the W3C specifications repository to the new home of https://github.com/qt4cg/qtspecs and I intend to use that as the location for managing the specs and tracking issues. There's a W3C mailing list which you can join at https://www.w3.org/community/xslt-40/, and I propose to use that for general discussions. Signing up to the W3C list makes you a member of the group, but the GitHub project is open to all. The mailing list is public-xslt-40@w3.org

Norm has promised to set up a continuous integration process so that commits to the repository automatically generate new HTML specs, but in the meantime you can find the current state of play by digging down into the repository.

I'm not planning to do anything grandiose: nothing as ambitious or as disruptive as schema-awareness in 2.0, or streaming in 3.0. I see it mainly as completing unfinished business: working with maps and arrays and JSON, in particular, has revealed gaps in functionality that it shouldn't be too hard to fix. We've already been plugging some of these gaps in Saxon with extensions, but it would be much better for everyone if we have community discussion and consensus before extensions are implemented.

My personal interest is more in XSLT and XPath than XQuery, but changes to XPath and the function library impact XQuery as well, so participation from people whose primary interest is XQuery is more than welcome.

Michael Kay

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS