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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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
>>>
>>>
>>
>>
>
>