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
