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
<[email protected] <mailto:[email protected]>>
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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
------------------------------------------------------------------------------
_______________________________________________
Xsltforms-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
