xsltforms-support

[Xsltforms-support] Rev. 548: Performance fix for xml namespace support with Firefox

[Alain C. <ala...@ag...>]

Hello,

I have just fixed a big performance issue due to XML namespace being 
used in XPath expression (for example, in @xml:lang).

It was strongly slowing the transformation step (more than twelve 
seconds in a rather simple test form!).

BTW, the namespace:: axis is not yet supported by Mozilla XSLT engine...

Thank you for your feedbacks!

-Alain

Re: [Xsltforms-support] Rev. 548: Performance fix for xml namespace support with Firefox

[Ihe O. <ihe...@go...>]

Are there any instructions or particular guidelines for those of us
who installed and are runnnig XSLTForms via eXist?

On Wed, Jul 4, 2012 at 8:54 PM, Alain Couthures
<ala...@ag...> wrote:
> Hello,
>
> I have just fixed a big performance issue due to XML namespace being
> used in XPath expression (for example, in @xml:lang).
>
> It was strongly slowing the transformation step (more than twelve
> seconds in a rather simple test form!).
>
> BTW, the namespace:: axis is not yet supported by Mozilla XSLT engine...
>
> Thank you for your feedbacks!
>
> -Alain
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support

[Xsltforms-support] hiding/displaying groups

[Jens Ø. P. <oe...@gm...>]

Hello,

I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,

<xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">

My problem is that this works with fine with xsltforms-1.0RC, but not with revisions 547-549 (the only revisions I have tested).

This has nothing to do with the namespaced attributes. It has nothing to do with elements versus attributes. Length also does not have anything to do with it.

By the way: what would be the version number of xsltforms-1.0RC (so I can test when the behaviour changed)?

Best,

Jens

On Jul 4, 2012, at 9:54 PM, Alain Couthures wrote:

> Hello,
> 
> I have just fixed a big performance issue due to XML namespace being 
> used in XPath expression (for example, in @xml:lang).
> 
> It was strongly slowing the transformation step (more than twelve 
> seconds in a rather simple test form!).
> 
> BTW, the namespace:: axis is not yet supported by Mozilla XSLT engine...
> 
> Thank you for your feedbacks!
> 
> -Alain
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] hiding/displaying groups

[Alain C. <ala...@ag...>]

Hello Jens,
> I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,
>
> <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">
First, I would try to minimize such expressions like this, if there is 
one char that should not appear in values:
.[not(contains(concat('~',@altRepGroup,'~',@authority,'~',@authorityURI,'~',@displayLabel,'~',@ID,'~',@lang,'~',@nameTitleGroup,'~',.....,'~'),'~~'))] 

>
> My problem is that this works with fine with xsltforms-1.0RC, but not with revisions 547-549 (the only revisions I have tested).
In fact, many features and optimizations have been added since 
xsltforms-1.0RC and a new release candidate version should be published 
soon.
>
> This has nothing to do with the namespaced attributes. It has nothing to do with elements versus attributes. Length also does not have anything to do with it.
Usually to fix bugs, the tiniest test case is the best way to locate the 
issue. Can you please send me one?
>
> By the way: what would be the version number of xsltforms-1.0RC (so I can test when the behaviour changed)?
xsltforms.js, line 45:     fileVersionNumber: 535,

Thanks!

-Alain

Re: [Xsltforms-support] hiding/displaying groups

[Jens Ø. P. <oe...@gm...>]

Thanks, Alain,

The change came with 547.

I will see if I can extricate a tiny test case from my mass of xquery.

Trying to make one, I noticed that Firefox (up-to-date version on up-to-date OS X) treats the attached mods.2.xml file wrongly and Chrome treats it correctly, whereas mods1.xml is treated correctly by both. The way the namespaces are set makes the difference.

This does not illustrate my original problem, however, and has nothing to do with 547.

Cheers,

Jens

Re: [Xsltforms-support] hiding/displaying groups

[Alain C. <ala...@ag...>]

Le 10/07/2012 15:32, Jens Østergaard Petersen a écrit :
> The change came with 547.
>
> I will see if I can extricate a tiny test case from my mass of xquery.
OK
>
> Trying to make one, I noticed that Firefox (up-to-date version on up-to-date OS X) treats the attached mods.2.xml file wrongly and Chrome treats it correctly, whereas mods1.xml is treated correctly by both. The way the namespaces are set makes the difference.
>
> This does not illustrate my original problem, however, and has nothing to do with 547.
It's the namespace:: axis support issue in Firefox. The known workaround 
is to add, preferably at the document element, a dummy attribute such as 
mods:dummy="dummy".
> The idea (which works before 547) is that if one of the named nodes is 
> missing, a panel should show up; this contains a number of buttons for 
> inserting missing nodes, each of which is displayed, by its own 
> xf:group, if its node is not present in the instance. If I understand 
> you correctly, you are checking the values of the elements and 
> attributes listed. You will catch if there is an empty value (which 
> will bring a '~~'). I am checking if the instance has nodes with the 
> listed names as child elements or attributes of the context node. I 
> will catch a missing node. I could condense my "or" expression if I 
> could use not(name(.) = ('a','b','c')). 
XSLTForms doesn't support XPath 2.0 yet ;-)

Checking empty values vs. missing nodes is, of course, not exactly the 
same, depending on the context but missing nodes produce empty values in 
XPath 1.0!

Thanks!

-Alain

Re: [Xsltforms-support] hiding/displaying groups

[C. M. Sperberg-M. <cm...@bl...>]

On Jul 10, 2012, at 5:01 AM, Alain Couthures wrote:

> Hello Jens,
>> I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,
>> 
>> <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">
> First, I would try to minimize such expressions like this, if there is 
> one char that should not appear in values:
> .[not(contains(concat('~',@altRepGroup,'~',@authority,'~',@authorityURI,'~',@displayLabel,'~',@ID,'~',@lang,'~',@nameTitleGroup,'~',.....,'~'),'~~'))] 

For the case where we don't have any guarantees about the values
(so concatenating with '~' or any other magic character is not safe), I 
wonder (just thinking out loud here) if applying DeMorgan's Law to
produce a simpler expression would help:

  ref=".[not(@altRepGroup and @authority and @authorityURI and ...
               ... and @xlink:href)]"

Or even (if your list is all the attributes that are possible, which is 
alas probably not the case)

  ref=".[count(@*) &lt; 20]"

Not tested.

Michael

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] hiding/displaying groups

[Jens Ø. P. <oe...@gm...>]

Hello Michael,

Thank you for laying out the law!

Both your rewritings work fine. I wonder which one is the fastest?

Regards,

Jens

On Jul 10, 2012, at 9:55 PM, C. M. Sperberg-McQueen wrote:

> 
> On Jul 10, 2012, at 5:01 AM, Alain Couthures wrote:
> 
>> Hello Jens,
>>> I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,
>>> 
>>> <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">
>> First, I would try to minimize such expressions like this, if there is 
>> one char that should not appear in values:
>> .[not(contains(concat('~',@altRepGroup,'~',@authority,'~',@authorityURI,'~',@displayLabel,'~',@ID,'~',@lang,'~',@nameTitleGroup,'~',.....,'~'),'~~'))] 
> 
> For the case where we don't have any guarantees about the values
> (so concatenating with '~' or any other magic character is not safe), I 
> wonder (just thinking out loud here) if applying DeMorgan's Law to
> produce a simpler expression would help:
> 
>  ref=".[not(@altRepGroup and @authority and @authorityURI and ...
>               ... and @xlink:href)]"
> 

<xf:group class="show-hide" ref=".[not(mods:partName and mods:partNumber and @script and mods:subTitle and @supplied and mods:title and @transliteration and @type and @usage and @valueURI and @xml:lang and @xlink:href)]">

> Or even (if your list is all the attributes that are possible, which is 
> alas probably not the case)
> 
>  ref=".[count(@*) &lt; 20]"
> 
> Not tested.

<xf:group class="show-hide" ref=".[count(@*) &lt; 8 or count(*) &lt; 5]">

> 
> Michael
> 
> -- 
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com 
> * http://cmsmcq.com/mib                 
> * http://balisage.net
> ****************************************************************
> 
> 
> 
>