OK, I can see the difficulties with the design. Making a small change to a large document with XSLT is always problematic. Is it possible to avoid this, and keep all the "working data" in the HTML tree, using data-XX attributes for example?

Michael Kay
Saxonica


On 3 Jan 2014, at 17:27, Todd Gochenour <todd.gochenour@gmail.com> wrote:

Here's where I'm at today.  The initial bit about setParameter() was an idea that has been abandoned.  

This morning I wrote an initial identity transformation of the XML document that injects an '_id' attribute with generate-id(.) as the value into each element of the document.  This fixes these element id's for the life of the document.  Any inserts will likely have id's generated with a timestamp to keep them unique.  This initial transformation is performed before the HTML page is rendered.  The id's then are used in the HTML to map editable content back to the original XML document.  The XML and HTML are representations of the same data. When a blur event happens on a <span contenteditable="true"/>, The id of the element and the new text value are passed to a separate update transformation processor using transformToDocument().  Unfortunately, this identity transformation is too slow--like a second delay before focus appears on the next editable field.  I need a way to inject the value into the existing document.  Also my javascript 'xml' variable now points to a brand new document instance different from the one retained by the processor via the original call to updateHTMLDocument(). I see no way of updating the reference in the original processor other than perhaps calling updateHTMLDocument(xml) again.

As there is no javascript API for querying or modifying an XML document, next I need to investigate if there is a way to do updates using updateHTMLDocument(event,xml) where the second parameter points at the XML document instead of HTML and an <xsl:result-document href="?select=???"/> identifies the XML element that needs to be modified in-situ.  Eric van der Vlist's Amsterdam XML presentation hinted that this is possible.  If so, that will speed updates considerably and resolve the mismatch that occurs between the processor's xml ixsl:source() reference and the updated xml referenced in javascript.




On Fri, Jan 3, 2014 at 5:59 AM, Michael Kay <mike@saxonica.com> wrote:

On 3 Jan 2014, at 06:46, Todd Gochenour <todd.gochenour@gmail.com> wrote:

Continuing from my last post, I still haven't figured out how I should update the source document.  

I've worked a bit on the XML-to-XML transformation logic producing a copy of the original XML with one particular node updated in some way (for example, add new attribute or change text content).  The original XML is transformed into HTML where a <span contentEditable='true' id="something"/> is generated for each element in the doc.   I've tried two strategies, one using generate-id() and one generating an xpath expression to uniquely identify the element being modified.  Strategy one sets <span id="{generate-id()}"/>.  Strategy two sets <span path="{my:path(.)}"/> where my:path is a custom function generating "/step-one[1]/step-two[n]/.../step-n[m]".

Again, I'm afraid I haven't really understood what you are trying to do. Why is HTML involved when you want to transform XML to XML?


With strategy one, I'm afraid that document insertions will change the value of generated ids for elements that follow.  Is this true?  

We probably need to be more formal about the specification in this area: mutability of the HTML makes a lot of questions about stability a bit fuzzy. However, the current implementation for the HTML document wrapper uses an algorithm for generateId() that recalculates the ID on each call, and produces a result that is based on the sibling position of the node and each of its ancestors, which means that inserting new nodes will change the generateId() of its following-siblings.

I noticed that Saxon-CE, Saxon-HE and Saxon-EE (as run in oXygen) generate different values for the same elements in the same document.  Can I assume the ids will always be the same within the same transformation engine for the same document?

Only within the scope of a "transformation episode". When a new transformation is started (e.g. by an event firing), pending updates are applied, and a new transformation episode starts, therefore new IDs are generated.


With strategy two, it doesn't appear that saxon:evaluate() is implemented in Saxon-CE.  I could write a recursive template that splits the path on slash '/' and walks down through the document one step at a time.   What a pain.

It would also suffer the same problem of resilience to inserts.

 

I'm afraid that an identity transform of the entire document is a lot of work just to inject a text node within a particular element.  

Are we talking about HTML elements here? It should certainly be possible to avoid that. But I think that if you want stable IDs across an in-situ modification of the HTML document, then you will have to generate them yourself.

Michael Kay
Saxonica

Do I then have to re-render the entire page because ids or paths have changed?  Perhaps I should mark-up the original source document with id's before rendering the HTML so the ids in the document are fixed.  I could do this as an preliminary analysis XML-to-XML transformation and fix the id values in the document.

What to do?  I know I saw a model update in Eric van der Vlist's Amsterdam XML presentation.  He wrote a custom event processor to pass events between the View XSL and the Model XSL.  Perhaps there's an answer to be found there.  This presentation can be found here: http://vdv.re/A    The thing is, the Model XSL in Eric's presentation has hard-coded a match template for the particular node being updated.  I need a generic solution.   I'll give it another go tomorrow.


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help