[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Converting schema to schematron

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: Michael Kay <mike@saxonica.com>
  • Date: Mon, 14 Aug 2017 18:38:01 +1000

Re:  Converting schema to schematron
Yes, I think the availability of maps with dynamically allocated keys is a game changer, as far as this kind of complex pipelines is concerned. 

Being able to read the in-progress output tree would be a real help too, if it could be checkpointed to overcome the lack of execution order certainty.

(I guess I would like the ability to signify the end of a lifetime for a map or map entry, to allow immediate garbage collection/collectability, too.)

Regards
Rick

On 14 Aug 2017 17:54, "Michael Kay" <mike@saxonica.com> wrote:
>
> 3) It is difficult to structure and handle so many steps in a pipeline with XSLT.  There were lots of parts where a language with mutable tree would have been much more straightforward.

John Lumley has been working on (and presented at Balisage) an implementation of XSLT written in XSLT. This has similar challenges, I suspect. (I also touched on the issue years ago in my ExtremeMarkup paper on writing an optimizer in XSLT). I think we can solve the problem by maintaining intermediate data structures as lots of small XML trees indexed by maps and arrays. The reason these work better than XML trees is that we have efficient immutable implementations of maps and arrays: that is, implementations that are immutable at the level of the exposed operations, but where making a small change does not involve making a full copy -- for example we implement maps using an immutable hash trie.

I've been thinking about whether it's possible to have an implementation of XDM node-trees with similar properties, and I think I have convinced myself that we can: the key requirement is to get rid of parent pointers, which immediately makes subtrees shareable. Getting rid of parent pointers doesn't actually inhibit full XPath navigation, it just means that a "node" returned by an XPath expression is a composite of two things: persistent information about the underlying node in memory, and transient information about how you reached it, so that you can retrace your steps.

Once you have this basic support at the data structure level, you probably need to introduce operations that take advantage of it: rather like map:put which creates a new map as a modified copy of an existing map, with a delta implementation underneath, you need operations that create a new tree which is a delta copy of an existing tree differing only in small details, e.g. a change in the value of a single attribute.

Michael Kay
Saxonica




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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.