xsltforms-support — XSLTForms support list

Re: [Xsltforms-support] Slow bind

[Mark S. <m_s...@ma...>]

Hi Tim,
Thanks for that, show’s what a long time it is since I used bind in XForms! You
made me look at my misuse of syntax.
I have now replaced @ref with @nodeset and @value with @calculate and my form
has speeded up considerably, with the @calculate taking 5 seconds.

Best wishes
Mark

On Thu, Jan 21, 2016 at 1:01 pm, Tim Thompson <tim...@gm...> wrote:
Mark,

I'm probably missing something, but is @value a valid attribute for xf:bind?
Could this be collapsed into a single @ref expression?

Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Thu, Jan 21, 2016 at 6:10 AM, Mark Seaborne < m_s...@ma... [m_s...@ma...] > wrote:
Hi there,
I am using bind to carry out a simple code conversion. The bind looks like this:
<xf:bind ref="instance(‘x')/featureMember/item/code"
value="id(string(current()/../itemUID), instance(‘y'))/value[3]/code/@href”/>



I find that the bind really slows form loading time and form performance. The
bind takes 3 seconds in a very small form and more than 20 seconds in the real
form. There are about 360 records in each instance.
Does anyone have any suggestions as to how I could improve performance? I have
no control over the XML structures.
Best wishes
Mark
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311

Re: [Xsltforms-support] Slow bind

[Tim T. <tim...@gm...>]

Mark,

I'm probably missing something, but is @value a valid attribute for
xf:bind? Could this be collapsed into a single @ref expression?

Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Thu, Jan 21, 2016 at 6:10 AM, Mark Seaborne <m_s...@ma...> wrote:

> Hi there,
>
> I am using bind to carry out a simple code conversion. The bind looks like
> this:
>
> <xf:bind ref="instance(‘x')/featureMember/item/code"
> value="id(string(current()/../itemUID),
> instance(‘y'))/value[3]/code/@href”/>
>
>
> I find that the bind really slows form loading time and form performance.
> The bind takes 3 seconds in a very small form and more than 20 seconds in
> the real form. There are about 360 records in each instance.
>
> Does anyone have any suggestions as to how I could improve performance? I
> have no control over the XML structures.
>
> Best wishes
>
> Mark
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>

[Xsltforms-support] Another XSLT question

[Mark S. <m_s...@ma...>]

Hi Again,
In the documentation at
https://en.wikibooks.org/wiki/XSLTForms/The_transform_function it makes 
clear
that the transform() function takes either the URI of an external XSLT
stylesheet, or XSLT as a string.
I just wondered if the stylesheet can also be a node, like the XML to be
transformed?
Best wishes Mark

[Xsltforms-support] Slow bind

[Mark S. <m_s...@ma...>]

Hi there,
I am using bind to carry out a simple code conversion. The bind looks like this:
<xf:bind ref="instance(‘x')/featureMember/item/code"
value="id(string(current()/../itemUID), instance(‘y'))/value[3]/code/@href”/>



I find that the bind really slows form loading time and form performance. The
bind takes 3 seconds in a very small form and more than 20 seconds in the real
form. There are about 360 records in each instance.
Does anyone have any suggestions as to how I could improve performance? I have
no control over the XML structures.
Best wishes
Mark

Re: [Xsltforms-support] XSLTForms and SVG

[Tim T. <tim...@gm...>]

Alain,

Excellent--thank you for the explanation and solution! What is it with
Firefox and namespaces? :-)

Best regards,
Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Tue, Jan 19, 2016 at 1:08 PM, Alain Couthures <
ala...@ag...> wrote:

> Tim,
>
> Thank you for pointing at this issue!
>
> XSLTForms stylesheet has to deal with namespaces: the best approach for
> browsers appears to deliver no namespace for HTML. Using <xsl:copy> is not
> a good solution and using <xsl:element> and <xsl:attribute> allows to
> remove the XHTML namespace.
>
> BTW, with the previous template, Saxon was complaining that attributes
> cannot have attributes...
>
> So, I prefer improve the current templates with non-HTML namespaces
> support, such as SVG, at least for elements:
>
> <xsl:template match="*" priority="-2" xmlns:xhtml=
> "http://www.w3.org/1999/xhtml" <http://www.w3.org/1999/xhtml> xmlns:xsl=
> "http://www.w3.org/1999/XSL/Transform"
> <http://www.w3.org/1999/XSL/Transform>>
>     <xsl:param name="appearance" select="@appearance"/>
>     <xsl:param name="parentworkid"/>
>     <xsl:param name="workid"
> select="concat(position(),'_',$parentworkid)"/>
>     <xsl:choose>
>         <xsl:when test="namespace-uri() != '' and namespace-uri() != '
> http://www.w3.org/1999/xhtml'">
>             <xsl:element name="{local-name()}"
> namespace="{namespace-uri()}">
>                 <xsl:apply-templates select="@*"/>
>                 <xsl:apply-templates select="node()">
>                     <xsl:with-param name="parentworkid" select="$workid"/>
>                     <xsl:with-param name="appearance"
> select="$appearance"/>
>                 </xsl:apply-templates>
>             </xsl:element>
>         </xsl:when>
>         <xsl:otherwise>
>             <xsl:element name="{local-name()}">
>                 <xsl:apply-templates select="@*"/>
>                 <xsl:apply-templates select="node()">
>                     <xsl:with-param name="parentworkid" select="$workid"/>
>                     <xsl:with-param name="appearance"
> select="$appearance"/>
>                 </xsl:apply-templates>
>             </xsl:element>
>         </xsl:otherwise>
>     </xsl:choose>
> </xsl:template>
>
> I have successfully tested this with Firefox (Firefox is not anymore my
> default browser because of too many conformance, performance and freeze
> issues...).
>
> Thank you for your feedback!
>
> --Alain
>
>
> Le 19/01/2016 14:11, Tim Thompson a écrit :
>
> Alain,
>
> I am hoping to do some work with XForms and SVG and have been looking at
> the current XSLTForms SVG examples. I noticed that, since rev. 595 of
> XSLTForms, none of the SVG examples work in Firefox. The reason seems to be
> the changes made to the fallback identity template in xsltforms.xsl.
>
> In the latest revision, if lines 1203-1228[1] are reverted back to the
> template used prior to rev. 595, then the SVG examples will work in Firefox:
>
> <xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> match="node()|@*" priority="-2">
>     <xsl:param name="appearance" select="@appearance"/>
>     <xsl:param name="parentworkid"/>
>     <xsl:param name="workid"
> select="concat(position(),'_',$parentworkid)"/>
>     <xsl:copy>
>         <xsl:apply-templates select="@*"/>
>         <xsl:apply-templates select="node()">
>             <xsl:with-param name="parentworkid" select="$workid"/>
>             <xsl:with-param name="appearance" select="$appearance"/>
>         </xsl:apply-templates>
>     </xsl:copy>
> </xsl:template>
>
> Is there a reason not to use this more generic template? I tested on a
> range of browsers and did not notice any immediate issues.
>
> Thanks again!
> Tim
>
> [1]
> https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.xsl#L1203
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
>

Re: [Xsltforms-support] XSLTForms and SVG

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

Tim,

Thank you for pointing at this issue!

XSLTForms stylesheet has to deal with namespaces: the best approach for 
browsers appears to deliver no namespace for HTML. Using <xsl:copy> is 
not a good solution and using <xsl:element> and <xsl:attribute> allows 
to remove the XHTML namespace.

BTW, with the previous template, Saxon was complaining that attributes 
cannot have attributes...

So, I prefer improve the current templates with non-HTML namespaces 
support, such as SVG, at least for elements:

<xsl:template match="*" priority="-2" 
xmlns:xhtml="http://www.w3.org/1999/xhtml" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     <xsl:param name="appearance" select="@appearance"/>
     <xsl:param name="parentworkid"/>
     <xsl:param name="workid" 
select="concat(position(),'_',$parentworkid)"/>
     <xsl:choose>
         <xsl:when test="namespace-uri() != '' and namespace-uri() != 
'http://www.w3.org/1999/xhtml'">
             <xsl:element name="{local-name()}" 
namespace="{namespace-uri()}">
                 <xsl:apply-templates select="@*"/>
                 <xsl:apply-templates select="node()">
                     <xsl:with-param name="parentworkid" select="$workid"/>
                     <xsl:with-param name="appearance" 
select="$appearance"/>
                 </xsl:apply-templates>
             </xsl:element>
         </xsl:when>
         <xsl:otherwise>
             <xsl:element name="{local-name()}">
                 <xsl:apply-templates select="@*"/>
                 <xsl:apply-templates select="node()">
                     <xsl:with-param name="parentworkid" select="$workid"/>
                     <xsl:with-param name="appearance" 
select="$appearance"/>
                 </xsl:apply-templates>
             </xsl:element>
         </xsl:otherwise>
     </xsl:choose>
</xsl:template>

I have successfully tested this with Firefox (Firefox is not anymore my 
default browser because of too many conformance, performance and freeze 
issues...).

Thank you for your feedback!

--Alain

Le 19/01/2016 14:11, Tim Thompson a écrit :
> Alain,
>
> I am hoping to do some work with XForms and SVG and have been looking 
> at the current XSLTForms SVG examples. I noticed that, since rev. 595 
> of XSLTForms, none of the SVG examples work in Firefox. The reason 
> seems to be the changes made to the fallback identity template in 
> xsltforms.xsl.
>
> In the latest revision, if lines 1203-1228[1] are reverted back to the 
> template used prior to rev. 595, then the SVG examples will work in 
> Firefox:
>
> <xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
> match="node()|@*" priority="-2">
>     <xsl:param name="appearance" select="@appearance"/>
>     <xsl:param name="parentworkid"/>
>     <xsl:param name="workid" 
> select="concat(position(),'_',$parentworkid)"/>
>     <xsl:copy>
>         <xsl:apply-templates select="@*"/>
>         <xsl:apply-templates select="node()">
>             <xsl:with-param name="parentworkid" select="$workid"/>
>             <xsl:with-param name="appearance" select="$appearance"/>
>         </xsl:apply-templates>
>     </xsl:copy>
> </xsl:template>
>
> Is there a reason not to use this more generic template? I tested on a 
> range of browsers and did not notice any immediate issues.
>
> Thanks again!
> Tim
>
> [1] 
> https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.xsl#L1203
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>

[Xsltforms-support] XSLTForms and SVG

[Tim T. <tim...@gm...>]

Alain,

I am hoping to do some work with XForms and SVG and have been looking at
the current XSLTForms SVG examples. I noticed that, since rev. 595 of
XSLTForms, none of the SVG examples work in Firefox. The reason seems to be
the changes made to the fallback identity template in xsltforms.xsl.

In the latest revision, if lines 1203-1228[1] are reverted back to the
template used prior to rev. 595, then the SVG examples will work in Firefox:

<xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
match="node()|@*" priority="-2">
    <xsl:param name="appearance" select="@appearance"/>
    <xsl:param name="parentworkid"/>
    <xsl:param name="workid" select="concat(position(),'_',$parentworkid)"/>
    <xsl:copy>
        <xsl:apply-templates select="@*"/>
        <xsl:apply-templates select="node()">
            <xsl:with-param name="parentworkid" select="$workid"/>
            <xsl:with-param name="appearance" select="$appearance"/>
        </xsl:apply-templates>
    </xsl:copy>
</xsl:template>

Is there a reason not to use this more generic template? I tested on a
range of browsers and did not notice any immediate issues.

Thanks again!
Tim

[1]
https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.xsl#L1203


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

[Xsltforms-support] Using transform()

[Mark S. <m_s...@ma...>]

Hi,
I am experimenting with using the transform() function and would like to pass an
XML instance into a stylesheet as a parameter value. Using something along the
lines of
transform(instance(‘myInstance'), 'xslt/test.xsl',false, 'theTestXML',
instance(’newCodes’))







I can access the instance within my stylesheet as a string, but not as a
nodeset. Is it possible to do this?
Best wishes Mark

Re: [Xsltforms-support] Rev 628 error using .getInstanceDocument()

[Mark S. <m_s...@ma...>]

Hmm, I must have done something wrong when I copied the new build as I 
tried
copying again and everything works fine now :)
Best wishes
Mark

On Mon, Jan 11, 2016 at 10:58 am, Mark Seaborne <m_s...@ma...> wrote:
Hi,
I have just moved to rev 628 and some script that had been working fine now
returns the error:
ReferenceError: Can't find variable: XsltForms_context
I am assuming that it is related to the use of .getInstanceDocument() in 
the code. Is my code out-of-date in some way?
Best wishes
Mark
Here is a test form that gives me the error:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes"?>
<?css-conversion no?>
<html xmlns = "http://www.w3.org/1999/xhtml"
xmlns:xf = "http://www.w3.org/2002/xforms"
xmlns:ev = "http://www.w3.org/2001/xml-events" >

<head>
<title> Test </title>

<script type = "text/javascript" >
<![CDATA[
function getXML() {
var modelElem = document.getElementById("theModel");
xmlDoc = modelElem.getInstanceDocument("content");
}
]]>
</script>
<xf:model id = "theModel" >

<xf:instance id = "content" >
<doc> Hello </doc>
</xf:instance>

<xf:action ev:event = "xforms-ready" >
<xf:load resource = "javascript:getXML()" />
</xf:action>
</xf:model>


</head>
<body>
<p><xf:output ref = "instance('content')" /></p>
</body>
</html>

[Xsltforms-support] Rev 628 error using .getInstanceDocument()

[Mark S. <m_s...@ma...>]

Hi,
I have just moved to rev 628 and some script that had been working fine now
returns the error:
ReferenceError: Can't find variable: XsltForms_context
I am assuming that it is related to the use of .getInstanceDocument() in 
the code. Is my code out-of-date in some way?
Best wishes
Mark
Here is a test form that gives me the error:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes"?>
<?css-conversion no?>
<html xmlns = "http://www.w3.org/1999/xhtml"
xmlns:xf = "http://www.w3.org/2002/xforms"
xmlns:ev = "http://www.w3.org/2001/xml-events" >

<head>
<title> Test </title>

<script type = "text/javascript" >
<![CDATA[
function getXML() {
var modelElem = document.getElementById("theModel");
xmlDoc = modelElem.getInstanceDocument("content");
}
]]>
</script>
<xf:model id = "theModel" >

<xf:instance id = "content" >
<doc> Hello </doc>
</xf:instance>

<xf:action ev:event = "xforms-ready" >
<xf:load resource = "javascript:getXML()" />
</xf:action>
</xf:model>


</head>
<body>
<p><xf:output ref = "instance('content')" /></p>
</body>
</html>

Re: [Xsltforms-support] XSLTForms rev. 629

[Tim T. <tim...@gm...>]

Alain,

Sorry, please disregard my comments about the debug/profiler errors. I had
forgotten to remove the xf:split declaration from my code, and this was
preventing the page from rendering properly (the double banner is also gone
now).

Thanks for the update about the split action. Reading back over your
previous message[2], I realize that I had misunderstood your reference to
the "first item in sub-values." You're absolutely correct, the delimited
string often consists of two levels: a role term, and an associated agent
who performs the role, so the two would need to be separated, as you have
indicated.

All best,
Tim

[1]
https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.js#L297
[2]
http://sourceforge.net/p/xsltforms/mailman/xsltforms-support/thread/56595FD2.70000%40agencexml.com/#msg34654122

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library
693 Alexander Road, 2nd Floor
Princeton, New Jersey 08540

(609) 258-2597 (office)
(201) 423-9972 (mobile)
www.linkedin.com/in/timathompson
ta...@pr...

On Tue, Jan 5, 2016 at 3:48 PM, Alain Couthures <
ala...@ag...> wrote:

> Tim,
>
> Rev. 629 is just anticipating Chrome 48 being released while the new dev
> environment is not yet fully operational.
>
> The new folder structure is inspired from the one used by PhoneGap: HTML
> files at top level and subfolders for Javascript, CSS, ...
>
> The next revision will accept both structures so it will fix the debug
> banner issue.
>
> The debug footer is correctly rendered for me. Could you please post the
> full exception message?
>
> The split action has to be used with Fleur as DOM engine. I will send you
> a full test form as soon as possible.
>
> Thanks!
>
> --Alain
>
>
> Le 04/01/2016 20:54, Tim Thompson a écrit :
>
>> Alain,
>>
>> Happy 2016!
>>
>> Glad to start the year with a new revision of XSLTForms (629). When I
>> updated, I noticed a couple of issues with the profiler/debugger.
>>
>> 1. The relative path to the images in the debug banner is not set
>> correctly. An "img" directory is referenced, but it doesn't exist in the
>> main XSLTForms repository[1] (maybe this is from the xphoneforms app
>> structure?). Also, if I set the debug processing instruction to "yes," I
>> get a double debug banner at the head of the page.
>>
>> 2. The debug footer (xsltforms_console) is not being rendered correctly
>> (in Firefox 43, "TypeError: document.getElementById(...) is null").
>>
>> Finally, I noticed the addition of the xf:split action to the codebase
>> and tried to use it, following the example from your previous message, but
>> I was unsuccessful. I sometimes get an XSLTForms exception when I refresh
>> the page: "xforms:split is not supported." Is this action available in the
>> latest revision?
>>
>> Thanks again!
>> Tim
>>
>> [1]
>> https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.js#L198
>>
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>

Re: [Xsltforms-support] XSLTForms rev. 629

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

Tim,

Rev. 629 is just anticipating Chrome 48 being released while the new dev 
environment is not yet fully operational.

The new folder structure is inspired from the one used by PhoneGap: HTML 
files at top level and subfolders for Javascript, CSS, ...

The next revision will accept both structures so it will fix the debug 
banner issue.

The debug footer is correctly rendered for me. Could you please post the 
full exception message?

The split action has to be used with Fleur as DOM engine. I will send 
you a full test form as soon as possible.

Thanks!

--Alain

Le 04/01/2016 20:54, Tim Thompson a écrit :
> Alain,
>
> Happy 2016!
>
> Glad to start the year with a new revision of XSLTForms (629). When I 
> updated, I noticed a couple of issues with the profiler/debugger.
>
> 1. The relative path to the images in the debug banner is not set 
> correctly. An "img" directory is referenced, but it doesn't exist in 
> the main XSLTForms repository[1] (maybe this is from the xphoneforms 
> app structure?). Also, if I set the debug processing instruction to 
> "yes," I get a double debug banner at the head of the page.
>
> 2. The debug footer (xsltforms_console) is not being rendered 
> correctly (in Firefox 43, "TypeError: document.getElementById(...) is 
> null").
>
> Finally, I noticed the addition of the xf:split action to the codebase 
> and tried to use it, following the example from your previous message, 
> but I was unsuccessful. I sometimes get an XSLTForms exception when I 
> refresh the page: "xforms:split is not supported." Is this action 
> available in the latest revision?
>
> Thanks again!
> Tim
>
> [1] 
> https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.js#L198
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>

[Xsltforms-support] XSLTForms rev. 629

[Tim T. <tim...@gm...>]

Alain,

Happy 2016!

Glad to start the year with a new revision of XSLTForms (629). When I
updated, I noticed a couple of issues with the profiler/debugger.

1. The relative path to the images in the debug banner is not set
correctly. An "img" directory is referenced, but it doesn't exist in the
main XSLTForms repository[1] (maybe this is from the xphoneforms app
structure?). Also, if I set the debug processing instruction to "yes," I
get a double debug banner at the head of the page.

2. The debug footer (xsltforms_console) is not being rendered correctly (in
Firefox 43, "TypeError: document.getElementById(...) is null").

Finally, I noticed the addition of the xf:split action to the codebase and
tried to use it, following the example from your previous message, but I
was unsuccessful. I sometimes get an XSLTForms exception when I refresh the
page: "xforms:split is not supported." Is this action available in the
latest revision?

Thanks again!
Tim

[1]
https://github.com/AlainCouthures/xsltforms/blob/master/build/xsltforms.js#L198


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library
<ta...@pr...>

[Xsltforms-support] UI Events in XSLTForms

[Tim T. <tim...@gm...>]

Alain,

I was working through Steven Pemberton's excellent OpenStreetMap XForms
example[1] from XML Amsterdam, and I noticed that it does not work in the
latest version of XSLTForms (his demo is using XSLTForms RC1.0).

A small change introduced in rev. 620 appears to be the problem:
https://github.com/AlainCouthures/xsltforms/blob/972a712e47fb952255c25e15d437255aaa58b31a/src/js/xmlevtmngt/Listener.js.xml#L102

Removing "&& !(event instanceof UIEvent)" allows the mouse events to be
registered again. Is it safe to remove this condition?

Best regards,
Tim

[1] http://homepages.cwi.nl/~steven/Talks/2015/11-05-example/

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

Re: [Xsltforms-support] fn:tokenize in XSLTForms

[Tim T. <tim...@gm...>]

Alain,

This sounds great so far. Maybe it could even form the basis for more
robust mixed content editing extensions in XForms. There are use cases
(like TEI annotations[1]) that are not easily satisfied by RTE plugins,
which were designed for HTML editing. An XSLTForms Markdown parser could
also be interesting :-)

Regarding your questions, internal whitespace should be preserved when the
data is serialized, and any final punctuation (like periods) should be
maintained. Libraries in the U.S. follow the ISBD standard[2], which
defines how punctuation should be used in catalog records. Semicolons are
usually preceded and followed by a single whitespace character. Also, I'm
not sure about the first item in sub-values having a special meaning. It is
usually capitalized, but that is just a formatting issue, not because it
differs from the other values.

It's really too bad that, after creating structured data, it should have to
be serialized back to a string, but that is the limitation of current
cataloging formats (which is why we are trying to move to a new RDF-based
model).

Thank you for your work on this!

Tim

[1] Winona Salesky has done some very interesting work in this regard:
https://github.com/srophe/tei-editor
[2]
https://en.wikipedia.org/wiki/International_Standard_Bibliographic_Description

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Sat, Nov 28, 2015 at 3:03 AM, Alain Couthures <
ala...@ag...> wrote:

> Tim,
>
> This is now partially implemented and I would be happy to have your
> remarks.
>
> Enabling this feature for just some nodes is not easy with mediatype
> parameters. So, I have created a new action named "split" to create an
> array node according to a separator and to perform left and right trim
> according to a regular expression.
>
> For your test form, it sounds like this:
>
>       <xf:split ev:event="xforms-model-construct-done"
> ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag =
> '245']/marc:subfield[@code = 'c']" separator=";" left-trim="^\s\s*"
> right-trim="(\s|\.)\s*$"/>
>       <xf:split ev:event="xforms-model-construct-done"
> ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag =
> '508']/marc:subfield[@code = 'a']" separator=";" left-trim="^\s\s*"
> right-trim="(\s|\.)\s*$"/>
>       <xf:split ev:event="xforms-model-construct-done"
> ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag =
> '508']/marc:subfield[@code = 'a']/array()/text()" separator=","
> left-trim="^\s\s*" right-trim="(\s|\.)\s*$"/>
>       <xf:split ev:event="xforms-model-construct-done"
> ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag =
> '511']/marc:subfield[@code = 'a']" separator="," left-trim="^\s\s*"
> right-trim="(\s|\.)\s*$"/>
>
> As you can see, this action can be applied more than once on the same
> subfield in case of embedded separators such as ";" then ",". The right
> trim regular expression is able to remove the trailing ".". Maybe the "^"
> and the "$" should be automatically added...
>
> I have not yet implemented the new "+" feature for input so I have just
> tested with static input controls. It should be possible to add XForms
> triggers and actions to add/remove text items but I have not tested this
> yet:
>
>             <xf:group
>               ref="marc:datafield[@tag = '245']/marc:subfield[@code =
> 'c']/array()">
>               <xf:repeat nodeset="text()">
>                 <xf:input ref=".">
>                   <xf:label>Production credit: </xf:label>
>                 </xf:input>
>               </xf:repeat>
>             </xf:group>
>
> and
>             <xf:group ref="marc:datafield[@tag =
> '508']/marc:subfield[@code = 'a']/array()">
>                 <xf:repeat nodeset="array()">
>                     <xf:input ref="text()">
>                        <xf:label>Role: </xf:label>
>                     </xf:input>
>                     <xf:repeat nodeset="node()[preceding-sibling::node()]">
>                         <xf:input ref=".">
>                             <xf:label>Role by: </xf:label>
>                         </xf:input>
>                     </xf:repeat>
>                 </xf:repeat>
>             </xf:group>
>
> I have seen that the first item in sub-values has a special meaning so I
> have isolated it from the corresponding repeat. The corresponding XPath
> expression should naturally be "text()[preceding-sibling::text()]" but the
> XPath parser has currently an issue with it so I just tested with the more
> general expression "node()[preceding-sibling::node()]".
>
> This is not serialized back yet because I have questions about this. While
> the parsing separator can be just a single character, would not you prefer
> to have a serialized return with a separator followed by a single space
> character? Should the ending "." be added back? If so, my idea is to add
> attributes to the split action to allow the serializer to perform this.
> These parameters could be stored as attributes of the array node.
>
> What do you think?
>
> Alain
>
>
>
> Le 20/11/2015 18:50, Tim Thompson a écrit :
>
> Alain,
>
> This approach sounds very promising! Yes, I think it would be preferable
> to have the ability to specifically enable/disable the "+" feature as you
> suggest.
>
> Best regards,
> Tim
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Fri, Nov 20, 2015 at 12:13 PM, Alain Couthures <
> <ala...@ag...>ala...@ag...> wrote:
>
>> Tim,
>>
>> The best approach could be to mix the two approaches:
>>
>>    - let's define a mediatype such as "application/xml+csv" with an
>>    optional parameter named "separator"
>>    - add support for this new mediatype in Fleur, my new DOM
>>    implementation I presented at XML Amsterdam, so each text value containing
>>    a separator is splitted into an array node with as many text nodes as items
>>    - add support of arrays in XSLTForms input controls: as many HTML
>>    inputs as items with "+" and "-" buttons for each to add and delete items
>>    (every XForms input control for single strings will actually have a "+"
>>    button to allow to generate an array from them)
>>
>> Would it be better for you to specifically enable/disable the "+" feature
>> for, let's say, attributes, some elements, depending on the namespace, ...?
>>
>> What do you think?
>>
>> Alain
>>
>> Le 20/11/2015 04:26, Tim Thompson a écrit :
>>
>> Yes, library catalog data is notorious for using punctuation to indicate
>> structure (a legacy of the card catalog days).
>>
>> Your proposal seems like a great, declarative solution, and I think it
>> would be a valuable extension for XSLTForms. It could also be interesting
>> if the XForms 2.0 CSV2XML mapping could be applied to the text content of
>> individual elements (rather than only instances), so that it could be
>> accessed using XPath.
>>
>> Best regards,
>> Tim
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>> On Thu, Nov 19, 2015 at 3:36 PM, Alain Couthures <
>> <ala...@ag...>ala...@ag...> wrote:
>>
>>> Tim,
>>>
>>> This is a very interesting test case because it shows that some elements
>>> might contain multiple values separated by ";". It looks like CSV contents
>>> within elements!
>>>
>>> I don't think fn:tokenize is the right tool for this situation: it is
>>> designed for returning strings not nodes to be bound to controls. It is
>>> true that XSLTForms is using faked nodes for returning what can be seen as
>>> a sequence but it is just a trick for an XPath 1.0 engine.
>>>
>>> I have been thinking of a way for splitting the text node which is the
>>> child of the element into many and, then, it would be possible to bind them
>>> individually for editing. I am not sure that all DOM implementations in
>>> browsers will support adjacent text nodes without concatenate them. An
>>> XPath function should not modify nodes so a specific action would be
>>> required...
>>>
>>> It should be better, first, to consider that the element value has a
>>> specific data type, which is a restriction of xsd:string. As for RTE, the
>>> separator to be recognized can be associated to this data type. Then, the
>>> input control bound to each element with this data type will actually be
>>> rendered by XSLTForms with multiple HTML inputs, as many as sub-values, and
>>> with buttons to add and remove inputs. This would be developed as an XForms
>>> extension in XSLTForms.
>>>
>>> What do you think?
>>>
>>> Alain
>>>
>>>
>>> Le 18/11/2015 23:34, Tim Thompson a écrit :
>>>
>>> Alain,
>>>
>>> Thank you for your reply. Attached is a test case using fn:tokenize to
>>> create input controls. The purpose is to edit library catalog records for
>>> audiovisual material and transcribe information about production credits.
>>>
>>> Best regards,
>>> Tim
>>>
>>> --
>>> Tim A. Thompson
>>> Metadata Librarian (Spanish/Portuguese Specialty)
>>> Princeton University Library
>>>
>>>
>>> On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures <
>>> <ala...@ag...>ala...@ag...> wrote:
>>>
>>>> Tim,
>>>>
>>>> Currently, fn:tokenize() is returning faked text nodes. This is good
>>>> enough for xf:output and should also work with xf:setvalue.
>>>>
>>>> It would still be easy to create standalone text nodes owned by default
>>>> instance to do the trick more appropriately for complex cases.
>>>>
>>>> Could you please send me a test case?
>>>>
>>>> Thanks!
>>>>
>>>> --Alain
>>>>
>>>>
>>>> Le 18/11/2015 20:02, Tim Thompson a écrit :
>>>>
>>>> Alain,
>>>>
>>>> Can fn:tokenize be used to update instance data with xf:input, or only
>>>> to display data with xf:output? I have XML data with elements that contain
>>>> semicolon-delimited strings that I would like to split across separate
>>>> input controls, but I guess the data can't be updated once it is tokenized?
>>>>
>>>> Best wishes,
>>>> Tim
>>>>
>>>> --
>>>> Tim A. Thompson
>>>> Metadata Librarian (Spanish/Portuguese Specialty)
>>>> Princeton University Library
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xsltforms-support mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: [Xsltforms-support] fn:tokenize in XSLTForms

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

Tim,

This is now partially implemented and I would be happy to have your remarks.

Enabling this feature for just some nodes is not easy with mediatype 
parameters. So, I have created a new action named "split" to create an 
array node according to a separator and to perform left and right trim 
according to a regular expression.

For your test form, it sounds like this:

       <xf:split ev:event="xforms-model-construct-done" 
ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag 
= '245']/marc:subfield[@code = 'c']" separator=";" left-trim="^\s\s*" 
right-trim="(\s|\.)\s*$"/>
       <xf:split ev:event="xforms-model-construct-done" 
ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag 
= '508']/marc:subfield[@code = 'a']" separator=";" left-trim="^\s\s*" 
right-trim="(\s|\.)\s*$"/>
       <xf:split ev:event="xforms-model-construct-done" 
ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag 
= '508']/marc:subfield[@code = 'a']/array()/text()" separator="," 
left-trim="^\s\s*" right-trim="(\s|\.)\s*$"/>
       <xf:split ev:event="xforms-model-construct-done" 
ref="instance('result')/marc:collection/marc:record/marc:datafield[@tag 
= '511']/marc:subfield[@code = 'a']" separator="," left-trim="^\s\s*" 
right-trim="(\s|\.)\s*$"/>

As you can see, this action can be applied more than once on the same 
subfield in case of embedded separators such as ";" then ",". The right 
trim regular expression is able to remove the trailing ".". Maybe the 
"^" and the "$" should be automatically added...

I have not yet implemented the new "+" feature for input so I have just 
tested with static input controls. It should be possible to add XForms 
triggers and actions to add/remove text items but I have not tested this 
yet:

             <xf:group
               ref="marc:datafield[@tag = '245']/marc:subfield[@code = 
'c']/array()">
               <xf:repeat nodeset="text()">
                 <xf:input ref=".">
                   <xf:label>Production credit: </xf:label>
                 </xf:input>
               </xf:repeat>
             </xf:group>

and
             <xf:group ref="marc:datafield[@tag = 
'508']/marc:subfield[@code = 'a']/array()">
                 <xf:repeat nodeset="array()">
                     <xf:input ref="text()">
                        <xf:label>Role: </xf:label>
                     </xf:input>
                     <xf:repeat nodeset="node()[preceding-sibling::node()]">
                         <xf:input ref=".">
                             <xf:label>Role by: </xf:label>
                         </xf:input>
                     </xf:repeat>
                 </xf:repeat>
             </xf:group>

I have seen that the first item in sub-values has a special meaning so I 
have isolated it from the corresponding repeat. The corresponding XPath 
expression should naturally be "text()[preceding-sibling::text()]" but 
the XPath parser has currently an issue with it so I just tested with 
the more general expression "node()[preceding-sibling::node()]".

This is not serialized back yet because I have questions about this. 
While the parsing separator can be just a single character, would not 
you prefer to have a serialized return with a separator followed by a 
single space character? Should the ending "." be added back? If so, my 
idea is to add attributes to the split action to allow the serializer to 
perform this. These parameters could be stored as attributes of the 
array node.

What do you think?

Alain



Le 20/11/2015 18:50, Tim Thompson a écrit :
> Alain,
>
> This approach sounds very promising! Yes, I think it would be 
> preferable to have the ability to specifically enable/disable the "+" 
> feature as you suggest.
>
> Best regards,
> Tim
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Fri, Nov 20, 2015 at 12:13 PM, Alain Couthures 
> <ala...@ag... <mailto:ala...@ag...>> 
> wrote:
>
>     Tim,
>
>     The best approach could be to mix the two approaches:
>
>       * let's define a mediatype such as "application/xml+csv" with an
>         optional parameter named "separator"
>       * add support for this new mediatype in Fleur, my new DOM
>         implementation I presented at XML Amsterdam, so each text
>         value containing a separator is splitted into an array node
>         with as many text nodes as items
>       * add support of arrays in XSLTForms input controls: as many
>         HTML inputs as items with "+" and "-" buttons for each to add
>         and delete items (every XForms input control for single
>         strings will actually have a "+" button to allow to generate
>         an array from them)
>
>     Would it be better for you to specifically enable/disable the "+"
>     feature for, let's say, attributes, some elements, depending on
>     the namespace, ...?
>
>     What do you think?
>
>     Alain
>
>     Le 20/11/2015 04:26, Tim Thompson a écrit :
>>     Yes, library catalog data is notorious for using punctuation to
>>     indicate structure (a legacy of the card catalog days).
>>
>>     Your proposal seems like a great, declarative solution, and I
>>     think it would be a valuable extension for XSLTForms. It could
>>     also be interesting if the XForms 2.0 CSV2XML mapping could be
>>     applied to the text content of individual elements (rather than
>>     only instances), so that it could be accessed using XPath.
>>
>>     Best regards,
>>     Tim
>>
>>     --
>>     Tim A. Thompson
>>     Metadata Librarian (Spanish/Portuguese Specialty)
>>     Princeton University Library
>>
>>
>>     On Thu, Nov 19, 2015 at 3:36 PM, Alain Couthures
>>     <ala...@ag...
>>     <mailto:ala...@ag...>> wrote:
>>
>>         Tim,
>>
>>         This is a very interesting test case because it shows that
>>         some elements might contain multiple values separated by ";".
>>         It looks like CSV contents within elements!
>>
>>         I don't think fn:tokenize is the right tool for this
>>         situation: it is designed for returning strings not nodes to
>>         be bound to controls. It is true that XSLTForms is using
>>         faked nodes for returning what can be seen as a sequence but
>>         it is just a trick for an XPath 1.0 engine.
>>
>>         I have been thinking of a way for splitting the text node
>>         which is the child of the element into many and, then, it
>>         would be possible to bind them individually for editing. I am
>>         not sure that all DOM implementations in browsers will
>>         support adjacent text nodes without concatenate them. An
>>         XPath function should not modify nodes so a specific action
>>         would be required...
>>
>>         It should be better, first, to consider that the element
>>         value has a specific data type, which is a restriction of
>>         xsd:string. As for RTE, the separator to be recognized can be
>>         associated to this data type. Then, the input control bound
>>         to each element with this data type will actually be rendered
>>         by XSLTForms with multiple HTML inputs, as many as
>>         sub-values, and with buttons to add and remove inputs. This
>>         would be developed as an XForms extension in XSLTForms.
>>
>>         What do you think?
>>
>>         Alain
>>
>>
>>         Le 18/11/2015 23:34, Tim Thompson a écrit :
>>>         Alain,
>>>
>>>         Thank you for your reply. Attached is a test case using
>>>         fn:tokenize to create input controls. The purpose is to edit
>>>         library catalog records for audiovisual material and
>>>         transcribe information about production credits.
>>>
>>>         Best regards,
>>>         Tim
>>>
>>>         --
>>>         Tim A. Thompson
>>>         Metadata Librarian (Spanish/Portuguese Specialty)
>>>         Princeton University Library
>>>
>>>
>>>         On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures
>>>         <ala...@ag...
>>>         <mailto:ala...@ag...>> wrote:
>>>
>>>             Tim,
>>>
>>>             Currently, fn:tokenize() is returning faked text nodes.
>>>             This is good enough for xf:output and should also work
>>>             with xf:setvalue.
>>>
>>>             It would still be easy to create standalone text nodes
>>>             owned by default instance to do the trick more
>>>             appropriately for complex cases.
>>>
>>>             Could you please send me a test case?
>>>
>>>             Thanks!
>>>
>>>             --Alain
>>>
>>>
>>>             Le 18/11/2015 20:02, Tim Thompson a écrit :
>>>>             Alain,
>>>>
>>>>             Can fn:tokenize be used to update instance data with
>>>>             xf:input, or only to display data with xf:output? I
>>>>             have XML data with elements that contain
>>>>             semicolon-delimited strings that I would like to split
>>>>             across separate input controls, but I guess the data
>>>>             can't be updated once it is tokenized?
>>>>
>>>>             Best wishes,
>>>>             Tim
>>>>
>>>>             --
>>>>             Tim A. Thompson
>>>>             Metadata Librarian (Spanish/Portuguese Specialty)
>>>>             Princeton University Library
>>>>
>>>>
>>>>             ------------------------------------------------------------------------------
>>>>
>>>>
>>>>             _______________________________________________
>>>>             Xsltforms-support mailing list
>>>>             Xsl...@li...
>>>>             <mailto:Xsl...@li...>
>>>>             https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>
>>>
>>
>>
>
>

Re: [Xsltforms-support] fn:tokenize in XSLTForms

[Tim T. <tim...@gm...>]

Alain,

This approach sounds very promising! Yes, I think it would be preferable to
have the ability to specifically enable/disable the "+" feature as you
suggest.

Best regards,
Tim


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Fri, Nov 20, 2015 at 12:13 PM, Alain Couthures <
ala...@ag...> wrote:

> Tim,
>
> The best approach could be to mix the two approaches:
>
>    - let's define a mediatype such as "application/xml+csv" with an
>    optional parameter named "separator"
>    - add support for this new mediatype in Fleur, my new DOM
>    implementation I presented at XML Amsterdam, so each text value containing
>    a separator is splitted into an array node with as many text nodes as items
>    - add support of arrays in XSLTForms input controls: as many HTML
>    inputs as items with "+" and "-" buttons for each to add and delete items
>    (every XForms input control for single strings will actually have a "+"
>    button to allow to generate an array from them)
>
> Would it be better for you to specifically enable/disable the "+" feature
> for, let's say, attributes, some elements, depending on the namespace, ...?
>
> What do you think?
>
> Alain
>
> Le 20/11/2015 04:26, Tim Thompson a écrit :
>
> Yes, library catalog data is notorious for using punctuation to indicate
> structure (a legacy of the card catalog days).
>
> Your proposal seems like a great, declarative solution, and I think it
> would be a valuable extension for XSLTForms. It could also be interesting
> if the XForms 2.0 CSV2XML mapping could be applied to the text content of
> individual elements (rather than only instances), so that it could be
> accessed using XPath.
>
> Best regards,
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Thu, Nov 19, 2015 at 3:36 PM, Alain Couthures <
> <ala...@ag...>ala...@ag...> wrote:
>
>> Tim,
>>
>> This is a very interesting test case because it shows that some elements
>> might contain multiple values separated by ";". It looks like CSV contents
>> within elements!
>>
>> I don't think fn:tokenize is the right tool for this situation: it is
>> designed for returning strings not nodes to be bound to controls. It is
>> true that XSLTForms is using faked nodes for returning what can be seen as
>> a sequence but it is just a trick for an XPath 1.0 engine.
>>
>> I have been thinking of a way for splitting the text node which is the
>> child of the element into many and, then, it would be possible to bind them
>> individually for editing. I am not sure that all DOM implementations in
>> browsers will support adjacent text nodes without concatenate them. An
>> XPath function should not modify nodes so a specific action would be
>> required...
>>
>> It should be better, first, to consider that the element value has a
>> specific data type, which is a restriction of xsd:string. As for RTE, the
>> separator to be recognized can be associated to this data type. Then, the
>> input control bound to each element with this data type will actually be
>> rendered by XSLTForms with multiple HTML inputs, as many as sub-values, and
>> with buttons to add and remove inputs. This would be developed as an XForms
>> extension in XSLTForms.
>>
>> What do you think?
>>
>> Alain
>>
>>
>> Le 18/11/2015 23:34, Tim Thompson a écrit :
>>
>> Alain,
>>
>> Thank you for your reply. Attached is a test case using fn:tokenize to
>> create input controls. The purpose is to edit library catalog records for
>> audiovisual material and transcribe information about production credits.
>>
>> Best regards,
>> Tim
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>> On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures <
>> <ala...@ag...>ala...@ag...> wrote:
>>
>>> Tim,
>>>
>>> Currently, fn:tokenize() is returning faked text nodes. This is good
>>> enough for xf:output and should also work with xf:setvalue.
>>>
>>> It would still be easy to create standalone text nodes owned by default
>>> instance to do the trick more appropriately for complex cases.
>>>
>>> Could you please send me a test case?
>>>
>>> Thanks!
>>>
>>> --Alain
>>>
>>>
>>> Le 18/11/2015 20:02, Tim Thompson a écrit :
>>>
>>> Alain,
>>>
>>> Can fn:tokenize be used to update instance data with xf:input, or only
>>> to display data with xf:output? I have XML data with elements that contain
>>> semicolon-delimited strings that I would like to split across separate
>>> input controls, but I guess the data can't be updated once it is tokenized?
>>>
>>> Best wishes,
>>> Tim
>>>
>>> --
>>> Tim A. Thompson
>>> Metadata Librarian (Spanish/Portuguese Specialty)
>>> Princeton University Library
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> Xsltforms-support mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>
>>>
>>>
>>
>>
>
>

Re: [Xsltforms-support] Replace text on xf:submission

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

Tim,

Thank you for pointing at this issue: the 
XsltForms_browser.loadTextNode() function is defined just for IE in the 
latest build.

Actually, this function can run on any DOM implementation so, for the 
next build, I will just move its declaration at main level for them all.

Can you move it manually just before this line:
  if (XsltForms_domEngine === "" && (XsltForms_browser.isIE || 
XsltForms_browser.isIE11)) {
and tell me if it works again for you??

Alain

Le 20/11/2015 18:08, Tim Thompson a écrit :
> Alain,
>
> Following up on the inner-CSV issue, I was doing some tests with the 
> BaseX CSV module (http://docs.basex.org/wiki/CSV_Module), which might 
> also be a convenient solution for my use case.
>
> However, in the latest version of XSLTForms, @replace="text" does not 
> seem to be working for xf:submission.
>
> For example, I just updated my version of XSLTForms here: 
> http://pulcams.github.io/
>
> The DBPedia example is using @replace="text", which was working under 
> rev. 618. Now a type error is thrown:
> TypeError: XsltForms_browser.loadTextNode is not a function
> Best regards,
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] fn:tokenize in XSLTForms

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

Tim,

The best approach could be to mix the two approaches:

  * let's define a mediatype such as "application/xml+csv" with an
    optional parameter named "separator"
  * add support for this new mediatype in Fleur, my new DOM
    implementation I presented at XML Amsterdam, so each text value
    containing a separator is splitted into an array node with as many
    text nodes as items
  * add support of arrays in XSLTForms input controls: as many HTML
    inputs as items with "+" and "-" buttons for each to add and delete
    items (every XForms input control for single strings will actually
    have a "+" button to allow to generate an array from them)

Would it be better for you to specifically enable/disable the "+" 
feature for, let's say, attributes, some elements, depending on the 
namespace, ...?

What do you think?

Alain

Le 20/11/2015 04:26, Tim Thompson a écrit :
> Yes, library catalog data is notorious for using punctuation to 
> indicate structure (a legacy of the card catalog days).
>
> Your proposal seems like a great, declarative solution, and I think it 
> would be a valuable extension for XSLTForms. It could also be 
> interesting if the XForms 2.0 CSV2XML mapping could be applied to the 
> text content of individual elements (rather than only instances), so 
> that it could be accessed using XPath.
>
> Best regards,
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Thu, Nov 19, 2015 at 3:36 PM, Alain Couthures 
> <ala...@ag... <mailto:ala...@ag...>> 
> wrote:
>
>     Tim,
>
>     This is a very interesting test case because it shows that some
>     elements might contain multiple values separated by ";". It looks
>     like CSV contents within elements!
>
>     I don't think fn:tokenize is the right tool for this situation: it
>     is designed for returning strings not nodes to be bound to
>     controls. It is true that XSLTForms is using faked nodes for
>     returning what can be seen as a sequence but it is just a trick
>     for an XPath 1.0 engine.
>
>     I have been thinking of a way for splitting the text node which is
>     the child of the element into many and, then, it would be possible
>     to bind them individually for editing. I am not sure that all DOM
>     implementations in browsers will support adjacent text nodes
>     without concatenate them. An XPath function should not modify
>     nodes so a specific action would be required...
>
>     It should be better, first, to consider that the element value has
>     a specific data type, which is a restriction of xsd:string. As for
>     RTE, the separator to be recognized can be associated to this data
>     type. Then, the input control bound to each element with this data
>     type will actually be rendered by XSLTForms with multiple HTML
>     inputs, as many as sub-values, and with buttons to add and remove
>     inputs. This would be developed as an XForms extension in XSLTForms.
>
>     What do you think?
>
>     Alain
>
>
>     Le 18/11/2015 23:34, Tim Thompson a écrit :
>>     Alain,
>>
>>     Thank you for your reply. Attached is a test case using
>>     fn:tokenize to create input controls. The purpose is to edit
>>     library catalog records for audiovisual material and transcribe
>>     information about production credits.
>>
>>     Best regards,
>>     Tim
>>
>>     --
>>     Tim A. Thompson
>>     Metadata Librarian (Spanish/Portuguese Specialty)
>>     Princeton University Library
>>
>>
>>     On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures
>>     <ala...@ag...
>>     <mailto:ala...@ag...>> wrote:
>>
>>         Tim,
>>
>>         Currently, fn:tokenize() is returning faked text nodes. This
>>         is good enough for xf:output and should also work with
>>         xf:setvalue.
>>
>>         It would still be easy to create standalone text nodes owned
>>         by default instance to do the trick more appropriately for
>>         complex cases.
>>
>>         Could you please send me a test case?
>>
>>         Thanks!
>>
>>         --Alain
>>
>>
>>         Le 18/11/2015 20:02, Tim Thompson a écrit :
>>>         Alain,
>>>
>>>         Can fn:tokenize be used to update instance data with
>>>         xf:input, or only to display data with xf:output? I have XML
>>>         data with elements that contain semicolon-delimited strings
>>>         that I would like to split across separate input controls,
>>>         but I guess the data can't be updated once it is tokenized?
>>>
>>>         Best wishes,
>>>         Tim
>>>
>>>         --
>>>         Tim A. Thompson
>>>         Metadata Librarian (Spanish/Portuguese Specialty)
>>>         Princeton University Library
>>>
>>>
>>>         ------------------------------------------------------------------------------
>>>
>>>
>>>         _______________________________________________
>>>         Xsltforms-support mailing list
>>>         Xsl...@li...
>>>         <mailto:Xsl...@li...>
>>>         https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>>
>
>

[Xsltforms-support] Replace text on xf:submission

[Tim T. <tim...@gm...>]

Alain,

Following up on the inner-CSV issue, I was doing some tests with the BaseX
CSV module (http://docs.basex.org/wiki/CSV_Module), which might also be a
convenient solution for my use case.

However, in the latest version of XSLTForms, @replace="text" does not seem
to be working for xf:submission.

For example, I just updated my version of XSLTForms here:
http://pulcams.github.io/

The DBPedia example is using @replace="text", which was working under rev.
618. Now a type error is thrown:

TypeError: XsltForms_browser.loadTextNode is not a function

Best regards,
Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

Re: [Xsltforms-support] fn:tokenize in XSLTForms

[Tim T. <tim...@gm...>]

Yes, library catalog data is notorious for using punctuation to indicate
structure (a legacy of the card catalog days).

Your proposal seems like a great, declarative solution, and I think it
would be a valuable extension for XSLTForms. It could also be interesting
if the XForms 2.0 CSV2XML mapping could be applied to the text content of
individual elements (rather than only instances), so that it could be
accessed using XPath.

Best regards,
Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Thu, Nov 19, 2015 at 3:36 PM, Alain Couthures <
ala...@ag...> wrote:

> Tim,
>
> This is a very interesting test case because it shows that some elements
> might contain multiple values separated by ";". It looks like CSV contents
> within elements!
>
> I don't think fn:tokenize is the right tool for this situation: it is
> designed for returning strings not nodes to be bound to controls. It is
> true that XSLTForms is using faked nodes for returning what can be seen as
> a sequence but it is just a trick for an XPath 1.0 engine.
>
> I have been thinking of a way for splitting the text node which is the
> child of the element into many and, then, it would be possible to bind them
> individually for editing. I am not sure that all DOM implementations in
> browsers will support adjacent text nodes without concatenate them. An
> XPath function should not modify nodes so a specific action would be
> required...
>
> It should be better, first, to consider that the element value has a
> specific data type, which is a restriction of xsd:string. As for RTE, the
> separator to be recognized can be associated to this data type. Then, the
> input control bound to each element with this data type will actually be
> rendered by XSLTForms with multiple HTML inputs, as many as sub-values, and
> with buttons to add and remove inputs. This would be developed as an XForms
> extension in XSLTForms.
>
> What do you think?
>
> Alain
>
>
> Le 18/11/2015 23:34, Tim Thompson a écrit :
>
> Alain,
>
> Thank you for your reply. Attached is a test case using fn:tokenize to
> create input controls. The purpose is to edit library catalog records for
> audiovisual material and transcribe information about production credits.
>
> Best regards,
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures <
> <ala...@ag...>ala...@ag...> wrote:
>
>> Tim,
>>
>> Currently, fn:tokenize() is returning faked text nodes. This is good
>> enough for xf:output and should also work with xf:setvalue.
>>
>> It would still be easy to create standalone text nodes owned by default
>> instance to do the trick more appropriately for complex cases.
>>
>> Could you please send me a test case?
>>
>> Thanks!
>>
>> --Alain
>>
>>
>> Le 18/11/2015 20:02, Tim Thompson a écrit :
>>
>> Alain,
>>
>> Can fn:tokenize be used to update instance data with xf:input, or only to
>> display data with xf:output? I have XML data with elements that contain
>> semicolon-delimited strings that I would like to split across separate
>> input controls, but I guess the data can't be updated once it is tokenized?
>>
>> Best wishes,
>> Tim
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Xsltforms-support mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>>
>>
>
>

Re: [Xsltforms-support] fn:tokenize in XSLTForms

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

Tim,

This is a very interesting test case because it shows that some elements 
might contain multiple values separated by ";". It looks like CSV 
contents within elements!

I don't think fn:tokenize is the right tool for this situation: it is 
designed for returning strings not nodes to be bound to controls. It is 
true that XSLTForms is using faked nodes for returning what can be seen 
as a sequence but it is just a trick for an XPath 1.0 engine.

I have been thinking of a way for splitting the text node which is the 
child of the element into many and, then, it would be possible to bind 
them individually for editing. I am not sure that all DOM 
implementations in browsers will support adjacent text nodes without 
concatenate them. An XPath function should not modify nodes so a 
specific action would be required...

It should be better, first, to consider that the element value has a 
specific data type, which is a restriction of xsd:string. As for RTE, 
the separator to be recognized can be associated to this data type. 
Then, the input control bound to each element with this data type will 
actually be rendered by XSLTForms with multiple HTML inputs, as many as 
sub-values, and with buttons to add and remove inputs. This would be 
developed as an XForms extension in XSLTForms.

What do you think?

Alain

Le 18/11/2015 23:34, Tim Thompson a écrit :
> Alain,
>
> Thank you for your reply. Attached is a test case using fn:tokenize to 
> create input controls. The purpose is to edit library catalog records 
> for audiovisual material and transcribe information about production 
> credits.
>
> Best regards,
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures 
> <ala...@ag... <mailto:ala...@ag...>> 
> wrote:
>
>     Tim,
>
>     Currently, fn:tokenize() is returning faked text nodes. This is
>     good enough for xf:output and should also work with xf:setvalue.
>
>     It would still be easy to create standalone text nodes owned by
>     default instance to do the trick more appropriately for complex cases.
>
>     Could you please send me a test case?
>
>     Thanks!
>
>     --Alain
>
>
>     Le 18/11/2015 20:02, Tim Thompson a écrit :
>>     Alain,
>>
>>     Can fn:tokenize be used to update instance data with xf:input, or
>>     only to display data with xf:output? I have XML data with
>>     elements that contain semicolon-delimited strings that I would
>>     like to split across separate input controls, but I guess the
>>     data can't be updated once it is tokenized?
>>
>>     Best wishes,
>>     Tim
>>
>>     --
>>     Tim A. Thompson
>>     Metadata Librarian (Spanish/Portuguese Specialty)
>>     Princeton University Library
>>
>>
>>     ------------------------------------------------------------------------------
>>
>>
>>     _______________________________________________
>>     Xsltforms-support mailing list
>>     Xsl...@li...
>>     <mailto:Xsl...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>

Re: [Xsltforms-support] format-number

[Ioan F. <mi...@gm...>]

Hi Alain,

Thank you for interest and involvement. I think that the type should 
remain valid xsd:dateTime. And, perhaps more important than the seconds, 
it would be the possibility to restrict the minutes to dozens or 
quarters of an hour, because it's uncomfortable to choose from the list 
of 60 positions.

For me it's good anyway, as to be easier to implement for you.

Thanks,
Ioan



On 11/18/2015 11:08 PM, Alain Couthures wrote:
> Hi Ioan,
>
> Restricting the calendar widget for seconds input is an interesting 
> idea because I presume that users are rarely interested in seconds 
> setting.
>
> I can see 2 possibilities: would you prefer to restrict the value with 
> a data type or to set options for the widget without restricting the 
> value? In the first situation, a correct value for xsd:dateTime could 
> be invalid for the restricted data type while, in the second 
> situation, a correct value for xsd:dateTime would always be valid.
>
> The way XSLTForms is designed will, in both situations, require to 
> define a new data type. For the second situation, it could be 
> implemented as for options for RTE.
>
> What do you think?
>
> Alain
>

Re: [Xsltforms-support] fn:tokenize in XSLTForms

[Tim T. <tim...@gm...>]

Alain,

Thank you for your reply. Attached is a test case using fn:tokenize to
create input controls. The purpose is to edit library catalog records for
audiovisual material and transcribe information about production credits.

Best regards,
Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


On Wed, Nov 18, 2015 at 3:57 PM, Alain Couthures <
ala...@ag...> wrote:

> Tim,
>
> Currently, fn:tokenize() is returning faked text nodes. This is good
> enough for xf:output and should also work with xf:setvalue.
>
> It would still be easy to create standalone text nodes owned by default
> instance to do the trick more appropriately for complex cases.
>
> Could you please send me a test case?
>
> Thanks!
>
> --Alain
>
>
> Le 18/11/2015 20:02, Tim Thompson a écrit :
>
> Alain,
>
> Can fn:tokenize be used to update instance data with xf:input, or only to
> display data with xf:output? I have XML data with elements that contain
> semicolon-delimited strings that I would like to split across separate
> input controls, but I guess the data can't be updated once it is tokenized?
>
> Best wishes,
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Xsltforms-support mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>
>

Re: [Xsltforms-support] format-number

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

Hi Ioan,

Restricting the calendar widget for seconds input is an interesting idea 
because I presume that users are rarely interested in seconds setting.

I can see 2 possibilities: would you prefer to restrict the value with a 
data type or to set options for the widget without restricting the 
value? In the first situation, a correct value for xsd:dateTime could be 
invalid for the restricted data type while, in the second situation, a 
correct value for xsd:dateTime would always be valid.

The way XSLTForms is designed will, in both situations, require to 
define a new data type. For the second situation, it could be 
implemented as for options for RTE.

What do you think?

Alain

Le 16/11/2015 17:33, Ioan Fericel a écrit :
>
> Many thanks, Alain!  It's perfect, for output works like in XQuery.
>
> I usually use mixed configurations, but for Romanian localization of 
> the new properties I can propose the following:
>
> <format-number.decimal-separator-sign>,</format-number.decimal-separator-sign> 
>
> <format-number.exponent-separator-sign>e</format-number.exponent-separator-sign> 
>
> <format-number.grouping-separator-sign>.</format-number.grouping-separator-sign> 
>
> <format-number.infinity>Infinit</format-number.infinity>
> <format-number.minus-sign>-</format-number.minus-sign>
> <format-number.NaN>Nenumeric</format-number.NaN>
> <format-number.percent-sign>%</format-number.percent-sign>
> <format-number.per-mille-sign>&#x2030;</format-number.per-mille-sign>
>
> I now address (if I see that it can!) an another question, related to 
> calendar, for the fields of type xsd: dateTime.
>
> It may be possible to configure the time, for example, to not display 
> seconds, or  to shown the minutes only from 10 to 10 or from 15 to 15?
>
> All the best!
> Ioan
>
> On 11/15/2015 10:45 PM, Alain Couthures wrote:
>> Hi Ioan,
>>
>> The format-number() function is now supported in XPath expressions. 
>> This has been committed in source repositories.
>>
>> It can be used with 2 parameters only and signs to be used in picture 
>> are the ones for English: "." as decimal separator and so on. This 
>> way, pictures don't have to be rewritten for applications with 
>> multi-language support.
>>
>> New properties are now supported in config.xsl files to allow 
>> specific separators for a language. For example, for French:
>>
>> <format-number.decimal-separator-sign>,</format-number.decimal-separator-sign> 
>>
>> <format-number.exponent-separator-sign>.10^</format-number.exponent-separator-sign> 
>>
>>             <format-number.grouping-separator-sign> 
>> </format-number.grouping-separator-sign>
>> <format-number.infinity>Infini</format-number.infinity>
>> <format-number.minus-sign>-</format-number.minus-sign>
>>             <format-number.NaN>Non numérique</format-number.NaN>
>> <format-number.percent-sign>%</format-number.percent-sign>
>> <format-number.per-mille-sign>&#x2030;</format-number.per-mille-sign>
>>
>> Please send me corresponding values for your country.
>>
>> Thank you for your feedback!
>>
>> --Alain
>>
>
>