+1 And this suggestion kind of compensates your recent d-o-e proposal on xsl-list ;) (I didn’t even read the post in full because “d-o-e” is a kind of stopword for me, similar to “XSLT 1.0”, “CDATA”, or “named entity”.) Sorry fellow oXygenists for taking this off-topic. And Wendell, I hope you don’t mind a little teasing. Gerrit On 20.11.2013 16:49, Wendell Piez wrote:

Eliot and oXygenists,

Since oXygen won't save over the XML source, I'd have the transformation scenario display output in the the XML results, then save from there. Two steps, not one.

Adding to Eliot's request -- I know the usefulness of a generalized "run XSLT and update the document with the result" has been discussed, but I can't remember what the impediments are.

Something like an option in a transformation scenario to "replace source document"?

Along similar lines, if transformation scenarios could reference editor windows as well as files, one could write an XSLT, apply it to an XML, inspect the output in the results view, and save it (even over the original) if one liked it, or revise the XSLT and run it again if necessary. This can be done now with more overhead (we have to save the XSLT out first, then create a transformation scenario). Perhaps a particular buffer could be designated as a "sandbox" for such purposes (and contain XSLT or XQuery).

Of course it would be dangerous, but so are lots of power tools.

Cheers, Wendell

Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^

On Wed, Nov 20, 2013 at 12:05 AM, Eliot Kimber <ekimber@rsicms.com> wrote:

...

For the DITA RelaxNG support that will be in DITA 1.3 I want to implement an action that can be applied to RNG document type shell grammars that looks at each referenced module, gets its domains attribute contribution (which will be in a specific subelement within the referenced module, and add it to the right place in the shell (a pattern named “domains-att”).

This is of course easy to do with XSLT.

My question: what’s the best way to set this up in Oxygen so that I can just do an “update domains attribute” action when editing a document type shell schema?

Thanks,

Eliot

-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com

_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

---

oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

-- Gerrit Imsieke Geschäftsführer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@le-tex.de, http://www.le-tex.de Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930 Geschäftsführer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard Vöckler

Hi Wendell, You cannot read and write in XSLT the same file. However, if your XSLT takes the document as input and outputs the transformed document then there is nothing that stops you from configuring the output of the transformation scenario to be the current file, use ${cf} in the "Save As" field of the Output tab when you setup the transformation scenario. Then, you can apply your processing by double clicking on the scenario in the Transformation Scenarios dialog - the nice effect of this is that the content in the editor will be automatically refreshed with the change, as we check this and load automatically the file from disk if it is changed - just make sure the file is saved before invoking the transformation, otherwise you will be asked if you want to reload the content from disk. The added bonus is that you also have undo support after you perform the change you can easily go back to the previous state if you are unhappy with the new document content. I just tested a clear stylesheet like <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"> <xsl:template match="node() | @*"> <xsl:copy> <xsl:apply-templates select="node() | @*"/> </xsl:copy> </xsl:template> <xsl:template match="text()"> <xsl:if test="normalize-space(.)=''"><xsl:copy-of select="."/></xsl:if> </xsl:template> </xsl:stylesheet> that will preserve the indenting but will clear all text content from the current document. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 11/21/13, 6:06 PM, Wendell Piez wrote:

Gerrit, you leave a misimpression that I suggested the OP use d-o-e, when in fact I was holding my nose when I copied that bit of his code. (I copied the code with one hand while I held my nose with the other.) I even offered that he should perhaps consider using a character map instead. I guess you missed that part. :-P

I actually don't think d-o-e is always evil. Just usually. Maybe always in XSLT 2.0. But it is sometimes useful to commandeer the XSLT serializer to produce non-XML outputs even with method="xml", and in 1.0 ... maybe a case of one evil begetting another?

Plus, didn't you like my innovative and elegant use of for-each-group[@group-by='true()'] to avoid a redundant tree traversal into the descendants he wanted to collect?

Back to oXygen -- let's see what George has to say about my impossible feature request (some way to "modify" an original file with XSLT). I am not above using the debugger, as a stopgap, to accomplish the same end (running a transformation and replacing an original with its transformation result).

Cheers, Wendell

Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^

On Wed, Nov 20, 2013 at 11:00 AM, Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de> wrote:

...

+1

And this suggestion kind of compensates your recent d-o-e proposal on xsl-list ;)

(I didn’t even read the post in full because “d-o-e” is a kind of stopword for me, similar to “XSLT 1.0”, “CDATA”, or “named entity”.)

Sorry fellow oXygenists for taking this off-topic. And Wendell, I hope you don’t mind a little teasing.

Gerrit

On 20.11.2013 16:49, Wendell Piez wrote:

...

Eliot and oXygenists,

Since oXygen won't save over the XML source, I'd have the transformation scenario display output in the the XML results, then save from there. Two steps, not one.

Adding to Eliot's request -- I know the usefulness of a generalized "run XSLT and update the document with the result" has been discussed, but I can't remember what the impediments are.

Something like an option in a transformation scenario to "replace source document"?

Along similar lines, if transformation scenarios could reference editor windows as well as files, one could write an XSLT, apply it to an XML, inspect the output in the results view, and save it (even over the original) if one liked it, or revise the XSLT and run it again if necessary. This can be done now with more overhead (we have to save the XSLT out first, then create a transformation scenario). Perhaps a particular buffer could be designated as a "sandbox" for such purposes (and contain XSLT or XQuery).

Of course it would be dangerous, but so are lots of power tools.

Cheers, Wendell

Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^

On Wed, Nov 20, 2013 at 12:05 AM, Eliot Kimber <ekimber@rsicms.com> wrote:

...

For the DITA RelaxNG support that will be in DITA 1.3 I want to implement an action that can be applied to RNG document type shell grammars that looks at each referenced module, gets its domains attribute contribution (which will be in a specific subelement within the referenced module, and add it to the right place in the shell (a pattern named “domains-att”).

This is of course easy to do with XSLT.

My question: what’s the best way to set this up in Oxygen so that I can just do an “update domains attribute” action when editing a document type shell schema?

Thanks,

Eliot

-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com

_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

---

oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

-- Gerrit Imsieke Geschäftsführer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard Vöckler _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

---

oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

Hi Steven, If I remember correctly the undo buffer was reset if the file was reloaded from disk at some point in the past but the undo support was improved and now it should work also after reloading the file from disk. Git support in oXygen is not on our short term plans now, but this is recorded on our issue tracking system and its priority may change in the future. One issue with these external XSLT transformations is that they do not preserve DOCTYPE information and XSLT also does not see entities, they will be replaced with their expansion text. We had also at the oXygen users meetup last Sunday requests to provide support for custom actions, like we have for the Author editing mode, also in the Text editing mode. Such custom actions can use the XSLTOperation which is configured with an XSLT script but you can also control what is the input and what happens with the result, so you can process only a part of the document and avoid some of the issues, like loosing the DOCTYPE for example. There is also an idea of allowing XSLT processing over the current document but done only on the root element and after entities are translated to text by replacing for example &entity; with &entity; - oXygen then will just replace the root element in the document and will convert & back to & to put entities back. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 11/22/13, 7:03 PM, Steven Anderson wrote:

I can verify that works. I did it once accidentally lost a bit of work. I don't think undo worked for me. Ever since I've been using git a lot more, even on working sets.

Speaking of which, any chance to add git support. I'm sure I can do pretty much everything I want using custom external tools, but I haven't really tried it.

On Fri, Nov 22, 2013 at 8:03 AM, George Cristian Bina <george@oxygenxml.com <mailto:george@oxygenxml.com>> wrote:

Hi Wendell,

You cannot read and write in XSLT the same file.

However, if your XSLT takes the document as input and outputs the transformed document then there is nothing that stops you from configuring the output of the transformation scenario to be the current file, use ${cf} in the "Save As" field of the Output tab when you setup the transformation scenario.

Then, you can apply your processing by double clicking on the scenario in the Transformation Scenarios dialog - the nice effect of this is that the content in the editor will be automatically refreshed with the change, as we check this and load automatically the file from disk if it is changed - just make sure the file is saved before invoking the transformation, otherwise you will be asked if you want to reload the content from disk. The added bonus is that you also have undo support after you perform the change you can easily go back to the previous state if you are unhappy with the new document content.

I just tested a clear stylesheet like

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">

<xsl:template match="node() | @*"> <xsl:copy> <xsl:apply-templates select="node() | @*"/> </xsl:copy> </xsl:template>

<xsl:template match="text()"> <xsl:if test="normalize-space(.)=''"><xsl:copy-of select="."/></xsl:if> </xsl:template>

</xsl:stylesheet>

that will preserve the indenting but will clear all text content from the current document.

Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

On 11/21/13, 6:06 PM, Wendell Piez wrote: > Gerrit, you leave a misimpression that I suggested the OP use d-o-e, > when in fact I was holding my nose when I copied that bit of his code. > (I copied the code with one hand while I held my nose with the other.) > I even offered that he should perhaps consider using a character map > instead. I guess you missed that part. :-P > > I actually don't think d-o-e is always evil. Just usually. Maybe > always in XSLT 2.0. But it is sometimes useful to commandeer the XSLT > serializer to produce non-XML outputs even with method="xml", and in > 1.0 ... maybe a case of one evil begetting another? > > Plus, didn't you like my innovative and elegant use of > for-each-group[@group-by='true()'] to avoid a redundant tree traversal > into the descendants he wanted to collect? > > Back to oXygen -- let's see what George has to say about my impossible > feature request (some way to "modify" an original file with XSLT). I > am not above using the debugger, as a stopgap, to accomplish the same > end (running a transformation and replacing an original with its > transformation result). > > Cheers, Wendell > > Wendell Piez | http://www.wendellpiez.com > XML | XSLT | electronic publishing > Eat Your Vegetables > _____oo_________o_o___ooooo____ooooooo_^ > > > On Wed, Nov 20, 2013 at 11:00 AM, Imsieke, Gerrit, le-tex > <gerrit.imsieke@le-tex.de <mailto:gerrit.imsieke@le-tex.de>> wrote: >> +1 >> >> And this suggestion kind of compensates your recent d-o-e proposal on >> xsl-list ;) >> >> (I didn’t even read the post in full because “d-o-e” is a kind of >> stopword for me, similar to “XSLT 1.0”, “CDATA”, or “named entity”.) >> >> Sorry fellow oXygenists for taking this off-topic. And Wendell, I hope >> you don’t mind a little teasing. >> >> Gerrit >> >> On 20.11.2013 16:49, Wendell Piez wrote: >>> Eliot and oXygenists, >>> >>> Since oXygen won't save over the XML source, I'd have the >>> transformation scenario display output in the the XML results, then >>> save from there. Two steps, not one. >>> >>> Adding to Eliot's request -- I know the usefulness of a generalized >>> "run XSLT and update the document with the result" has been discussed, >>> but I can't remember what the impediments are. >>> >>> Something like an option in a transformation scenario to "replace >>> source document"? >>> >>> Along similar lines, if transformation scenarios could reference >>> editor windows as well as files, one could write an XSLT, apply it to >>> an XML, inspect the output in the results view, and save it (even over >>> the original) if one liked it, or revise the XSLT and run it again if >>> necessary. This can be done now with more overhead (we have to save >>> the XSLT out first, then create a transformation scenario). Perhaps a >>> particular buffer could be designated as a "sandbox" for such purposes >>> (and contain XSLT or XQuery). >>> >>> Of course it would be dangerous, but so are lots of power tools. >>> >>> Cheers, Wendell >>> >>> Wendell Piez | http://www.wendellpiez.com >>> XML | XSLT | electronic publishing >>> Eat Your Vegetables >>> _____oo_________o_o___ooooo____ooooooo_^ >>> >>> >>> On Wed, Nov 20, 2013 at 12:05 AM, Eliot Kimber <ekimber@rsicms.com <mailto:ekimber@rsicms.com>> wrote: >>>> For the DITA RelaxNG support that will be in DITA 1.3 I want to implement >>>> an action that can be applied to RNG document type shell grammars that >>>> looks at each referenced module, gets its domains attribute contribution >>>> (which will be in a specific subelement within the referenced module, and >>>> add it to the right place in the shell (a pattern named “domains-att”). >>>> >>>> This is of course easy to do with XSLT. >>>> >>>> My question: what’s the best way to set this up in Oxygen so that I can >>>> just do an “update domains attribute” action when editing a document type >>>> shell schema? >>>> >>>> Thanks, >>>> >>>> Eliot >>>> >>>> -- >>>> Eliot Kimber >>>> Senior Solutions Architect >>>> "Bringing Strategy, Content, and Technology Together" >>>> Main: 512.554.9368 <tel:512.554.9368> >>>> www.reallysi.com <http://www.reallysi.com> >>>> www.rsuitecms.com <http://www.rsuitecms.com> >>>> >>>> >>>> _______________________________________________ >>>> oXygen-user mailing list >>>> oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> >>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user >>> _______________________________________________ >>> oXygen-user mailing list >>> oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> >>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user >>> >> >> -- >> Gerrit Imsieke >> Geschäftsführer / Managing Director >> le-tex publishing services GmbH >> Weissenfelser Str. 84, 04229 Leipzig, Germany >> Phone +49 341 355356 110 <tel:%2B49%20341%20355356%20110>, Fax +49 341 355356 510 <tel:%2B49%20341%20355356%20510> >> gerrit.imsieke@le-tex.de <mailto:gerrit.imsieke@le-tex.de>, http://www.le-tex.de >> >> Registergericht / Commercial Register: Amtsgericht Leipzig >> Registernummer / Registration Number: HRB 24930 >> >> Geschäftsführer: Gerrit Imsieke, Svea Jelonek, >> Thomas Schmidt, Dr. Reinhard Vöckler >> _______________________________________________ >> oXygen-user mailing list >> oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> >> http://www.oxygenxml.com/mailman/listinfo/oxygen-user > _______________________________________________ > oXygen-user mailing list > oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> > http://www.oxygenxml.com/mailman/listinfo/oxygen-user > _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> http://www.oxygenxml.com/mailman/listinfo/oxygen-user

--

Steve

Hi George, On Fri, Nov 22, 2013 at 11:03 AM, George Cristian Bina <george@oxygenxml.com> wrote:

You cannot read and write in XSLT the same file.

Indeed.

However, if your XSLT takes the document as input and outputs the transformed document then there is nothing that stops you from configuring the output of the transformation scenario to be the current file, use ${cf} in the "Save As" field of the Output tab when you setup the transformation scenario.

Then, you can apply your processing by double clicking on the scenario in the Transformation Scenarios dialog - the nice effect of this is that the content in the editor will be automatically refreshed with the change, as we check this and load automatically the file from disk if it is changed - just make sure the file is saved before invoking the transformation, otherwise you will be asked if you want to reload the content from disk. The added bonus is that you also have undo support after you perform the change you can easily go back to the previous state if you are unhappy with the new document content.

Nice tip: I will try this. Of course this is a delicate operation. In some ways XSLT is not suited to the task, since (as you note) the architecture isn't designed to support it. By the time you've set up all the tooling, you may as well do it the old-fashioned way. (Whatever you consider that to be. :-) Cheers, Wendell Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^

Hello, One aspect of using XQuery Update is that it will discard the DOCTYPE and will also expand entities. So you might not end up with what you've expected. We're investigating ways on our part to compensate for this inherent losses. Best regards, Alex -- Alex Jitianu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 25-Nov-13 5:54 PM, Eliot Kimber wrote:

I was thinking the XQuery update seemed like the appropriate modify-in-place semantic and the type of processing I’m thinking of in this case could be done easily enough with XQuery, although maybe not quite as conveniently as with XSLT.

Cheers,

E.

Hi Wendell, For entities we were thinking to turn them into text before processing and make them back to entities after processing, for example &something; will be converted to &something; and apply the reverse on the result. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 12/2/13, 4:22 PM, Wendell Piez wrote:

Hi,

On Thu, Nov 28, 2013 at 1:45 AM, Alex Jitianu <alex_jitianu@sync.ro> wrote:

...

Hello,

One aspect of using XQuery Update is that it will discard the DOCTYPE and will also expand entities. So you might not end up with what you've expected. We're investigating ways on our part to compensate for this inherent losses.

Yes. The same issue arises of course using XSLT.

In the case of XSLT, I can imagine a post-process that would work by performing a (non-XML) parse of the source document to scan for a DOCTYPE declaration and for entity references, find the declarations for the latter, and generate an XSLT near-identity transformation that would serve as a post-process to restore them.

It wouldn't be perfect, as it would effectively normalize entity references, and it would only work for entities that expand to single characters. On the other hand it might be good enough for daily wear.

(I guess it would have to map all declared entities, not only those used, since the results could conceivably include content not in the source. It would also have to be optional, since there would be cases when switching a document type or cleaning up entities might be the point of the process.)

I would be sympathetic to those who felt this sort of complication demonstrates that the functionality isn't a good idea in the architecture. Certainly, it would be a good way to shoot yourself in the foot.

Cheers, Wendell _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

One way to preserve entities during a process is to pre-process the file to double-escape the entity references. That is, transform < into &lt; before processing and transform them back again afterwards. This was a standard pattern in OmniMark, where you could easily stream the file through a filter on the way into and out of the parser. It should be doable in XSLT2, perhaps a little less elegantly, using the unparsed-text function. In *NIX you could do it with pipes on the command line. Mark

-----Original Message----- From: oxygen-user-bounces@oxygenxml.com [mailto:oxygen-user- bounces@oxygenxml.com] On Behalf Of Wendell Piez Sent: December 2, 2013 9:22 AM To: Alex Jitianu Cc: oxygen-user@oxygenxml.com Subject: Re: [oXygen-user] Custom action to process a document and update an element?

Hi,

On Thu, Nov 28, 2013 at 1:45 AM, Alex Jitianu <alex_jitianu@sync.ro> wrote:

...

Hello,

One aspect of using XQuery Update is that it will discard the DOCTYPE and will also expand entities. So you might not end up with what you've expected. We're investigating ways on our part to compensate for this inherent losses.

Yes. The same issue arises of course using XSLT.

In the case of XSLT, I can imagine a post-process that would work by performing a (non-XML) parse of the source document to scan for a DOCTYPE declaration and for entity references, find the declarations for the latter, and generate an XSLT near-identity transformation that would serve as a post-process to restore them.

It wouldn't be perfect, as it would effectively normalize entity references, and it would only work for entities that expand to single characters. On the other hand it might be good enough for daily wear.

(I guess it would have to map all declared entities, not only those used, since the results could conceivably include content not in the source. It would also have to be optional, since there would be cases when switching a document type or cleaning up entities might be the point of the process.)

I would be sympathetic to those who felt this sort of complication demonstrates that the functionality isn't a good idea in the architecture. Certainly, it would be a good way to shoot yourself in the foot.

Cheers, Wendell _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user