Implementors please read: poll about select1 and empty values

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementors please read: poll about select1 and empty values

Klotz, Leigh
A question has come up about conformance and interoperability of XForms processors with regard to the behavior of select1 when a value is the empty string or whitespace only. 

This message is a poll to find out how select1 with an empty item/value element behaves in existing XForms 1.1 implementations.  Based on the results of this poll we may add additional test cases, additional clarification, issue an erratum, or propose new features for XForms 1.2. 

Background:

The XForms 1.1 Recommendation says [1] about select1 (and select as well):
 
"For both closed and open selections, any selection item with a storage value which is empty or which contains only white space characters must remain deselected."

Discussion:
Nick van den Bleeken tentatively reported that least one implementation supports a select1/item/label for the empty item/value.

John Boyer and I both noted that select has this implementation requirement because its space-separated values in list content are indistinguishable from empty.  In short, the absence of any selected item is ithe indication that no item is selected.

John further noted, however, that the requirement on select1 is motivated not only by consistency with select, but also by another point, that the "required" MIP be used to indicate that a value has been set.  John noted that xsi:nil can also be used for this purpose, but is not well understood or implemented. 

John suggested to form designers that a "none" value for any select1 control-bound data would better be represented by a distinguished value chosen by the application, e.g. "none" or "n", rather than an empty value.

I noted that only if the XForms application and the data are co-designed can the form designer can satisfy this requirement, and that web resources may require an empty string to indicate a value of "none," and that allowing a binding of a label gives form designers the ability to express this UI.

As a result of this discussion, we are polling implementations and seeking feedback on the presentation and behavior of empty ref node values and empty item/value (and by extension, itemset) in select1.

Test Case:

I have produced a test and made it work using xsltforms.
It is available at http://xformstest.org/2010/12/select1-empty and please choose select1-empty.xml
We're asking implementors to adapt and run this test case and report behavior.
A sample report is below:

Test Case Results Example
For the sample I produced, here are the results for the select1 cases with an empty item/value.
(The test page also includes controls with no empty item/value).

no appearance:
displays as pulldown menu
empty value displays as a blank item inside select1. (to spec)
selecting the "(empty)" labeled item causes only that control to change. (partially to spec)
after that, selecting the unlabeled item causes all form controls bound to the node to change to the "(empty)" labeled item (not to spec)
selecting the "full" labeled item causes all controls to change to "full". (to spec)
selecting the "full" labeled item causes the blank item to disappear from all select1 controls, however the explicit "(empty)" choice remains. selecting the "(enpty)" labeled item again causes the blank item to re-appear in all select1 controls (???)


appearance=minimal:
displays as pulldown menu
same behavior as above

appearance=compact
displays as in-place visible menus with one selection allowed
same behavior as above

appearance="full"
displays as radio buttons; no blank or unlabeled radio button
empty value displays as a selected "(empty)" radio button. (NOT to spec)
selecting the "(empty)" labeled item causes all form controls to change to display the unlabeled item. (to spec)
selecting the "full" labeled item causes all controls to change to "full". (to spec)
selecting the "full" labeled item causes the blank item to disappear from all select1 controls, however the explicit "(empty)" choice remains;
selecting the "(empty)" labeled item again causes the blank item to re-appear in all select1 controls. (???)

Of the above, only the full appearance (radio) had a notable behavior: it offered no way to choose the empty item, and if the empty item were chosen by another control, it displayed with no selection.

Leigh.


[1] http://www.w3.org/TR/xforms11/#ui-selectOne
Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

John Boyer

Modulo my comments about why the spec might have originally contained that language (consistency, required MIP), this topic rings a bell as having been discussed and decided, perhaps a couple of years back, and that perhaps the human error of not creating an action item to fix the spec may have caused us to... not fix the spec.

The bell I seem to recall is that we wanted the possibility of getting a select1 back into the "unselected" state.  One can already do this for a select by simply unselecting everything, but for a select1 the only way to do it is to have an item with an empty value.  I seem to recall our concluding that a form author who doesn't like that feature in his forms has options for simply not using that feature.  Further, if the select1 is bound to a required node, it is of no consequence that the user's choice puts the form back into an unsubmittable state.  If that is undesirable, then it is because the form incorrectly designates the node as required.

As for answering the implementers poll, the IBM Forms product implements the ability of a select1 control to choose an item whose value is empty.  The emptiness is transmitted to the data node to which the select1 is bound.  If that data node is required, then the form control reverts to a display state that indicates the user must make a choice.

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: "Leigh L. Klotz, Jr." <[hidden email]>
To: [hidden email]
Cc: [hidden email]
Date: 12/08/2010 10:17 AM
Subject: Implementors please read: poll about select1 and empty values





A question has come up about conformance and interoperability of XForms processors with regard to the behavior of select1 when a value is the empty string or whitespace only.  

This message is a poll to find out how select1 with an empty item/value element behaves in existing XForms 1.1 implementations.  Based on the results of this poll we may add additional test cases, additional clarification, issue an erratum, or propose new features for XForms 1.2.  

Background:

The XForms 1.1 Recommendation says [1] about select1 (and select as well):
 

"For both closed and open selections, any selection item with a storage value which is empty or which contains only white space characters must remain deselected."

Discussion:
Nick van den Bleeken tentatively reported that least one implementation supports a select1/item/label for the empty item/value.

John Boyer and I both noted that select has this implementation requirement because its space-separated values in list content are indistinguishable from empty.  In short, the absence of any selected item is ithe indication that no item is selected.

John further noted, however, that the requirement on select1 is motivated not only by consistency with select, but also by another point, that the "required" MIP be used to indicate that a value has been set.  John noted that xsi:nil can also be used for this purpose, but is not well understood or implemented.  

John suggested to form designers that a "none" value for any select1 control-bound data would better be represented by a distinguished value chosen by the application, e.g. "none" or "n", rather than an empty value.

I noted that only if the XForms application and the data are co-designed can the form designer can satisfy this requirement, and that web resources may require an empty string to indicate a value of "none," and that allowing a binding of a label gives form designers the ability to express this UI.

As a result of this discussion, we are polling implementations and seeking feedback on the presentation and behavior of empty ref node values and empty item/value (and by extension, itemset) in select1.

Test Case:


I have produced a test and made it work using xsltforms.
It is available at
http://xformstest.org/2010/12/select1-empty and please choose select1-empty.xml
We're asking implementors to adapt and run this test case and report behavior.
A sample report is below:

Test Case Results Example

For the sample I produced, here are the results for the select1 cases with an empty item/value.
(The test page also includes controls with no empty item/value).

no appearance:
displays as pulldown menu
empty value displays as a blank item inside select1. (to spec)
selecting the "(empty)" labeled item causes only that control to change. (partially to spec)
after that, selecting the unlabeled item causes all form controls bound to the node to change to the "(empty)" labeled item (not to spec)
selecting the "full" labeled item causes all controls to change to "full". (to spec)
selecting the "full" labeled item causes the blank item to disappear from all select1 controls, however the explicit "(empty)" choice remains. selecting the "(enpty)" labeled item again causes the blank item to re-appear in all select1 controls (???)


appearance=minimal:
displays as pulldown menu
same behavior as above

appearance=compact
displays as in-place visible menus with one selection allowed
same behavior as above

appearance="full"
displays as radio buttons; no blank or unlabeled radio button
empty value displays as a selected "(empty)" radio button. (NOT to spec)
selecting the "(empty)" labeled item causes all form controls to change to display the unlabeled item. (to spec)
selecting the "full" labeled item causes all controls to change to "full". (to spec)
selecting the "full" labeled item causes the blank item to disappear from all select1 controls, however the explicit "(empty)" choice remains;
selecting the "(empty)" labeled item again causes the blank item to re-appear in all select1 controls. (???)

Of the above, only the full appearance (radio) had a notable behavior: it offered no way to choose the empty item, and if the empty item were chosen by another control, it displayed with no selection.

Leigh.


[1]
http://www.w3.org/TR/xforms11/#ui-selectOne

Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

Klotz, Leigh
On 12/09/2010 08:40 AM, John Boyer wrote:

...
As for answering the implementers poll, the IBM Forms product implements the ability of a select1 control to choose an item whose value is empty.  The emptiness is transmitted to the data node to which the select1 is bound.  If that data node is required, then the form control reverts to a display state that indicates the user must make a choice.

John,
Does this mean that IBM Forms allows the first item below to be selected, and conversely selects that item if the bound data node is the empty string?  That's what my test was intended to find out, and what I believe at least some other implementations do.

  <select ref="data">
   <label>data</data>
   <item>
     <label>(None)</label>
     <value />
   </item>
   <item>
     <label>full</label>
     <value>full</value>
   </item>
  </select1/>


Thank you,
Leigh.

Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

John Boyer

(Just found I didn't hit send on this several hours ago).

Yes, absolutely.  

In fact, I ran a slightly larger version of the test, which is a proper superset of the one you have below.

I used three items and put the empty one in the middle so I could be sure that the item selected on empty string was being selected for that reason and not due to some first/last default selection mechanism.  

I also bound both a dropdown and a radio button group to the data node so that I could see how different UI presentations of select1 behaved.  In particular, our dropdowns don't tend to select stuff in the drop down menu, but a radio group obviously does, so there's no doubt about what our processor is doing.

Finally, I also added a required="true()" MIP on the "data" node so that I could observe the behavior of the controls when the item with empty value was selected and deselected.

When my test form comes up, the data value is initially empty, and both the dropdown and radio group have the "required but empty countenance.
If I select the first item of the dropdown menu, the non-empty value is transmitted to data, and the radio group changes to the first selection.  Both controls lose the "required but empty" countenance.
If I then select the second item in the dropdown menu, the empty value is transmitted to data, and the radio group changes to the second item.  Both controls regain the "required but empty" countenance.
The consistent behaviors continue to happen upon selection of the third item with a non-empty value and also when I do this whole sequence from the radio group and observe what the dropdown shows and does.
That being said, I did also insert an xforms output control bound to the data node so I could directly see what it was being set to as well.

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Leigh L Klotz Jr <[hidden email]>
To: John Boyer/CanWest/IBM@IBMCA
Cc: [hidden email], [hidden email]
Date: 12/09/2010 10:14 AM
Subject: Re: Implementors please read: poll about select1 and empty values





On 12/09/2010 08:40 AM, John Boyer wrote:

...
As for answering the implementers poll, the IBM Forms product implements the ability of a select1 control to choose an item whose value is empty.  The emptiness is transmitted to the data node to which the select1 is bound.  If that data node is required, then the form control reverts to a display state that indicates the user must make a choice.


John,
Does this mean that IBM Forms allows the first item below to be selected, and conversely selects that item if the bound data node is the empty string?  That's what my test was intended to find out, and what I believe at least some other implementations do.

 <select ref="data">
  <label>data</data>
  <item>
    <label>(None)</label>
    <value />
  </item>
  <item>
    <label>full</label>
    <value>full</value>
  </item>
 </select1/>


Thank you,
Leigh.


Reply | Threaded
Open this post in threaded view
|

Proposition for JSON internal storage for XForms

Alain COUTHURES
In reply to this post by Klotz, Leigh
Hello,

Please find below my proposition for an internal storage in XML 1.0 for JSON objects allowing intuitive XPath expressions.

I'm writing a paper for XML Prague 2011 about implementing this in XSLTForms. This is the corresponding extract.

Thank you for your feedbacks.

-Alain

JSON for XForms
Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

Erik Bruchez
In reply to this post by Klotz, Leigh
All,

I haven't yet had time to fully dig into this, but our implementation
seems to trim strings on both sides before comparison, but only on
initial show of the page to indicatedthe initially-selected item. That
would be a bug!

Other than that, the Orbeon behavior is to do an exact string match
with select1 (as pointed out, it doesn't for select).

(BTW Leigh, I can't seem to run your test case page right now.)

-Erik

On Wed, Dec 8, 2010 at 10:09 AM, Leigh L. Klotz, Jr.
<[hidden email]> wrote:

> A question has come up about conformance and interoperability of XForms
> processors with regard to the behavior of select1 when a value is the empty
> string or whitespace only.
>
> This message is a poll to find out how select1 with an empty item/value
> element behaves in existing XForms 1.1 implementations.  Based on the
> results of this poll we may add additional test cases, additional
> clarification, issue an erratum, or propose new features for XForms 1.2.
>
> Background:
> The XForms 1.1 Recommendation says [1] about select1 (and select as well):
>
>
> "For both closed and open selections, any selection item with a storage
> value which is empty or which contains only white space characters must
> remain deselected."
>
> Discussion:
> Nick van den Bleeken tentatively reported that least one implementation
> supports a select1/item/label for the empty item/value.
>
> John Boyer and I both noted that select has this implementation requirement
> because its space-separated values in list content are indistinguishable
> from empty.  In short, the absence of any selected item is ithe indication
> that no item is selected.
>
> John further noted, however, that the requirement on select1 is motivated
> not only by consistency with select, but also by another point, that the
> "required" MIP be used to indicate that a value has been set.  John noted
> that xsi:nil can also be used for this purpose, but is not well understood
> or implemented.
>
> John suggested to form designers that a "none" value for any select1
> control-bound data would better be represented by a distinguished value
> chosen by the application, e.g. "none" or "n", rather than an empty value.
>
> I noted that only if the XForms application and the data are co-designed can
> the form designer can satisfy this requirement, and that web resources may
> require an empty string to indicate a value of "none," and that allowing a
> binding of a label gives form designers the ability to express this UI.
>
> As a result of this discussion, we are polling implementations and seeking
> feedback on the presentation and behavior of empty ref node values and empty
> item/value (and by extension, itemset) in select1.
>
> Test Case:
>
> I have produced a test and made it work using xsltforms.
> It is available at http://xformstest.org/2010/12/select1-empty and please
> choose select1-empty.xml
> We're asking implementors to adapt and run this test case and report
> behavior.
> A sample report is below:
>
> Test Case Results Example
> For the sample I produced, here are the results for the select1 cases with
> an empty item/value.
> (The test page also includes controls with no empty item/value).
>
> no appearance:
> displays as pulldown menu
> empty value displays as a blank item inside select1. (to spec)
> selecting the "(empty)" labeled item causes only that control to change.
> (partially to spec)
> after that, selecting the unlabeled item causes all form controls bound to
> the node to change to the "(empty)" labeled item (not to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains.
> selecting the "(enpty)" labeled item again causes the blank item to
> re-appear in all select1 controls (???)
>
>
> appearance=minimal:
> displays as pulldown menu
> same behavior as above
>
> appearance=compact
> displays as in-place visible menus with one selection allowed
> same behavior as above
>
> appearance="full"
> displays as radio buttons; no blank or unlabeled radio button
> empty value displays as a selected "(empty)" radio button. (NOT to spec)
> selecting the "(empty)" labeled item causes all form controls to change to
> display the unlabeled item. (to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains;
> selecting the "(empty)" labeled item again causes the blank item to
> re-appear in all select1 controls. (???)
>
> Of the above, only the full appearance (radio) had a notable behavior: it
> offered no way to choose the empty item, and if the empty item were chosen
> by another control, it displayed with no selection.
>
> Leigh.
>
>
> [1] http://www.w3.org/TR/xforms11/#ui-selectOne

Reply | Threaded
Open this post in threaded view
|

RE: Proposition for JSON internal storage for XForms

Nick Van den Bleeken-2
In reply to this post by Alain COUTHURES
JSON for XForms

Alain,

 

Great work! I like almost everything ;)

 

I have a couple remarks:

·         You could simplify the expressions by removing the ‘/*/’ the  initial context is the root element, so when the context isn’t changed you could write "/*/a[1]"  as just “a[1]” (which is more appealing)

·         Why use an attribute exsi:maxOccurs and not exsi:is-arry (in the examples only the presence or absence of unbound is used, so it cold be replaced by a boolean)

·         I don’t like the '________' it is hard to remember how many ‘_’ you have to type. Why not use something like ”exml:element” (better name is welcome)

·         I don’t like the section ‘XPath Engine Proposed Enhancements’ because it makes requires you to change the core XPath engine. In my opinion this will do more harm than it does good, because the standard selectors and functions will behave differently if you are accessing a JSON instance and one xpath expression could access both native XML instances and JSON instances. I’m afraid this will be confusing for both novice and experienced XPath users. (we could maybe us json-name() instead of fullname() and maybe do some other small tweaks to make life easier (e.g.: json-node(‘a’)  returns the node with name ‘a’ in the current context, in XPath 2.0 one can then write json-node(‘a’)[2] or json-node(‘a’)/ b/ json-node(‘1234’).

 

But overall the text describes a good solution for how json could be used in XForms.

 

Regards,

 

Nick Van den Bleeken

R&D Manager

 

Phone: +32 3 821 01 70

Office Fax: +32 3 821 01 71

[hidden email]

http://www.inventivedesigners.com

Linked in

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of COUTHURES Alain
Sent: zaterdag 11 december 2010 15:48
To: [hidden email]; [hidden email]
Subject: Proposition for JSON internal storage for XForms

 

Hello,

Please find below my proposition for an internal storage in XML 1.0 for JSON objects allowing intuitive XPath expressions.

I'm writing a paper for XML Prague 2011 about implementing this in XSLTForms. This is the corresponding extract.

Thank you for your feedbacks.

-Alain


Constraints

Reversibility

JSON objects have to be serialized identically to the original ones when not modified by controls.

XPath Full Support

New XPath extension functions should be enough to guaranty a full support.

Whenever extra elements are required for internal storage, their number should be minimal.

Javascript notation to retrieve an item in a array ([pos] where pos starts from 0) should be almost preserved ([pos] where pos starts from 1).

XML Schema conformance

XML Schema Recommendation already defines the xsi:type and the xsi:nil attributes and they are supported in the XForms Recommendation. The xsd:maxOccurs attribute enables to specify how many occurences there might be for an element.

Proposed Representation of JSON Objects With XML 1.0

Elements, Attributes and Namespaces

Elements are used for JSON values within the empty namespace.

Meta data are stored in attributes within a specific namespace.

Extra elements are limited and always in a specific namespace.

Extra Document Element

XML 1.0 requires a unique document element so such an element is always added.

Example:

{ a: "stringA", b: { c: "stringC", d: "stringD" } } 

would be serialized as:

<exml:noname xmlns:exml="http://www.agencexml.com/exml" xmlns="">
 <a>stringA</a>
 <b>
  <c>stringC</c>
  <d>stringD</d>
 </b>
</exml:noname>

and

·         "/*/a" equals 'stringA'

·         "/*/b/c" equals 'stringC'

·         "/*/b/d" equals 'stringD'

JSON Names

JSON names which cannot be used as XML names are replaced by '________' in the empty namespace.

An extra attribute is used to store the JSON name and the new XPath functions fullname() and local-fullname() are created to return its value.

Example:

{ "a & b": "A+B", "déjà": "already", "________": "undescores" }

are represented as:

<exml:noname xmlns:exml="http://www.agencexml.com/exml"
             xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
             xmlns:exsi="http://www.agencexml.com/exi" xmlns="">
 <________ exml:fullname="a &amp; b">A+B</________>
 <________ exml:fullname="déjà">already</________>
 <________ exml:fullname="________">underscores</________>
</exml:noname>

and

·         "/*/*[fullname() = 'a &amp; b']" equals 'A+B'

·         "local-fullname(/*/*[1])" equals 'a & b'

·         "/*/*[fullname() = 'déjà']" equals 'already'

·         "local-fullname(/*/*[2])" equals 'déjà'

·         "/*/________[fullname() = '________']" equals 'underscores'

JSON Datatypes

For each Javascript datatype, the most approaching XSD type is automatically associated. XForms bindings have to be used to adjust more precisely the effective datatype.

Example:

{ a: "string"+"A", b: 42, c: new Date(2011,3,26), d: true } 

would be serialized as:

<exml:noname xmlns:exml="http://www.agencexml.com/exml"
             xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns="">
 <a>stringA</a>
 <b xsi:type="xsd:double">42</b>
 <c xsi:type="xsd:dateTime">2011-03-26T00:00:00Z</c>
 <d xsi:type="xsd:boolean">true</d>
</exml:noname>

JSON Named Arrays

Arrays are modeled with an extra attribute. Empty arrays require another attribute because, if not, there would be an ambiguity for an array with just the empty string as element.

Extra XPath functions might be helpful:

·         is-array(node) which might be defined as "count(node[@exsi:maxOccurs = 'unbounded']) != 0"

·         array-length(node) which might be defined as "count(node[@exsi:maxOccurs = 'unbounded' and @xsi:nil != 'true'])"

Example:

{ a: ["stringA", 42], b: [], c: [""] } 

would be serialized as:

<exml:noname xmlns:exml="http://www.agencexml.com/exml"
             xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
             xmlns:exsi="http://www.agencexml.com/exi" xmlns="">
 <a exsi:maxOccurs="unbounded">stringA</a>
 <a exsi:maxOccurs="unbounded" xsi:type="xsd:double">42</a>
 <b exsi:maxOccurs="unbounded" xsi:nil="true"/>
 <c exsi:maxOccurs="unbounded"/>
</exml:noname>

and

·         "is-array(/*/a)" equals true()

·         "array-length(/*/a)" equals 2

·         "/*/a[1]" equals 'stringA'

·         "/*/a[2]" equals '42'

·         "is-array(/*/b)" equals true()

·         "array-length(/*/b)" equals 0

·         "is-array(/*/c)" equals true()

·         "array-length(/*/c)" equals 1

·         "/*/c[1]" equals ''

JSON Unnamed Arrays

An element with a reserved name in a specific namespace has to be used.

Example:

[ ["stringA", 42], [], [[]], { c: "stringC1", d: "stringD1" }, { c: "stringC2", d: "stringD2" } ]

would be serialized as:

<exml:noname xmlns:exml="http://www.agencexml.com/exml"
             xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
             xmlns:exsi="http://www.agencexml.com/exi" xmlns="">
 <exml:noname exsi:maxOccurs="unbounded">
  <exml:noname exsi:maxOccurs="unbounded">stringA</exml:noname>
  <exml:noname exsi:maxOccurs="unbounded" xsi:type="xsd:double">42</exml:noname>
 </exml:noname>
 <exml:noname exsi:maxOccurs="unbounded">
  <exml:noname exsi:maxOccurs="unbounded" xsi:nil="true"/>
 </exml:noname>
 <exml:noname exsi:maxOccurs="unbounded">
  <exml:noname exsi:maxOccurs="unbounded">
   <exml:noname exsi:maxOccurs="unbounded" xsi:nil="true"/>
  </exml:noname>
 </exml:noname>
 <exml:noname exsi:maxOccurs="unbounded">
  <c>stringC1</c>
  <d>stringD1</d>
 </exml:noname>
 <exml:noname exsi:maxOccurs="unbounded">
  <c>stringC2</c>
  <d>stringD2</d>
 </exml:noname>
</exml:noname>

and

·         "/*/*[1]/*[1]" equals 'stringA'

·         "/*/*[1]/*[2]" equals '42'

·         "is-array(/*/*[2])" equals true()

·         "is-array(/*/*[3]/*[1])" equals true()

·         "/*/*/c[../d = 'stringD1']" equals 'stringC1'

·         "/*/*[c = 'stringC2']/d" equals 'stringD2'

XPath Engine Proposed Enhancements

When possible, XPath engine modifications can simplify expressions for JSON objects:

·         non-XML names in expressions could be quoted with character ` (reverse quote) to avoid predicates with fullname() calls

·         name() and local-name() functions could be extended to support fullname() and local-fullname() functions and return '________' just when true

·         name() and local-name() functions could be modified to return '' (empty string) instead of, respectively, 'exml:noname' and 'noname'

·         "/*/" used for "/exml:noname/" could be simplified as just "/"'

·         "*" used for "exml:noname" could be written ``

·         "*" used for "exml:noname" before a predicate could even be omitted


--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--



Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--

Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

John Boyer
In reply to this post by Erik Bruchez

Hi Erik,

Quick notes:

1) The poll is not about the question you answered in this email.  I think we pretty much answered the original question with the "exact string match" behavior that you use everywhere except on initial load, so adjusting your initial load to be a string match without trimming would be best considering the answer we sent out already.

2) The poll question is asking what happens to a select1 when the ref of the select1 binds to a node with empty content and the select1 contains an item whose value is empty.  To make it easy, say you use appearance="full" so that you get a radio button group.  Let the item with the empty value be the middle of three item elements in the select1.  Does the radio group show no items selected or does it show the middle item as selected?

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Erik Bruchez <[hidden email]>
To: [hidden email], Forms WG <[hidden email]>
Date: 12/14/2010 11:20 PM
Subject: Re: Implementors please read: poll about select1 and empty values





All,

I haven't yet had time to fully dig into this, but our implementation
seems to trim strings on both sides before comparison, but only on
initial show of the page to indicatedthe initially-selected item. That
would be a bug!

Other than that, the Orbeon behavior is to do an exact string match
with select1 (as pointed out, it doesn't for select).

(BTW Leigh, I can't seem to run your test case page right now.)

-Erik

On Wed, Dec 8, 2010 at 10:09 AM, Leigh L. Klotz, Jr.
<[hidden email]> wrote:
> A question has come up about conformance and interoperability of XForms
> processors with regard to the behavior of select1 when a value is the empty
> string or whitespace only.
>
> This message is a poll to find out how select1 with an empty item/value
> element behaves in existing XForms 1.1 implementations.  Based on the
> results of this poll we may add additional test cases, additional
> clarification, issue an erratum, or propose new features for XForms 1.2.
>
> Background:
> The XForms 1.1 Recommendation says [1] about select1 (and select as well):
>
>
> "For both closed and open selections, any selection item with a storage
> value which is empty or which contains only white space characters must
> remain deselected."
>
> Discussion:
> Nick van den Bleeken tentatively reported that least one implementation
> supports a select1/item/label for the empty item/value.
>
> John Boyer and I both noted that select has this implementation requirement
> because its space-separated values in list content are indistinguishable
> from empty.  In short, the absence of any selected item is ithe indication
> that no item is selected.
>
> John further noted, however, that the requirement on select1 is motivated
> not only by consistency with select, but also by another point, that the
> "required" MIP be used to indicate that a value has been set.  John noted
> that xsi:nil can also be used for this purpose, but is not well understood
> or implemented.
>
> John suggested to form designers that a "none" value for any select1
> control-bound data would better be represented by a distinguished value
> chosen by the application, e.g. "none" or "n", rather than an empty value.
>
> I noted that only if the XForms application and the data are co-designed can
> the form designer can satisfy this requirement, and that web resources may
> require an empty string to indicate a value of "none," and that allowing a
> binding of a label gives form designers the ability to express this UI.
>
> As a result of this discussion, we are polling implementations and seeking
> feedback on the presentation and behavior of empty ref node values and empty
> item/value (and by extension, itemset) in select1.
>
> Test Case:
>
> I have produced a test and made it work using xsltforms.
> It is available at
http://xformstest.org/2010/12/select1-empty and please
> choose select1-empty.xml
> We're asking implementors to adapt and run this test case and report
> behavior.
> A sample report is below:
>
> Test Case Results Example
> For the sample I produced, here are the results for the select1 cases with
> an empty item/value.
> (The test page also includes controls with no empty item/value).
>
> no appearance:
> displays as pulldown menu
> empty value displays as a blank item inside select1. (to spec)
> selecting the "(empty)" labeled item causes only that control to change.
> (partially to spec)
> after that, selecting the unlabeled item causes all form controls bound to
> the node to change to the "(empty)" labeled item (not to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains.
> selecting the "(enpty)" labeled item again causes the blank item to
> re-appear in all select1 controls (???)
>
>
> appearance=minimal:
> displays as pulldown menu
> same behavior as above
>
> appearance=compact
> displays as in-place visible menus with one selection allowed
> same behavior as above
>
> appearance="full"
> displays as radio buttons; no blank or unlabeled radio button
> empty value displays as a selected "(empty)" radio button. (NOT to spec)
> selecting the "(empty)" labeled item causes all form controls to change to
> display the unlabeled item. (to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains;
> selecting the "(empty)" labeled item again causes the blank item to
> re-appear in all select1 controls. (???)
>
> Of the above, only the full appearance (radio) had a notable behavior: it
> offered no way to choose the empty item, and if the empty item were chosen
> by another control, it displayed with no selection.
>
> Leigh.
>
>
> [1]
http://www.w3.org/TR/xforms11/#ui-selectOne



Reply | Threaded
Open this post in threaded view
|

Re: Proposition for JSON internal storage for XForms

Alain COUTHURES
In reply to this post by Nick Van den Bleeken-2
Nick,
JSON for XForms

·         You could simplify the expressions by removing the ‘/*/’ the  initial context is the root element, so when the context isn’t changed you could write "/*/a[1]"  as just “a[1]” (which is more appealing)

Yes, I will improve my paper about that.

·         Why use an attribute exsi:maxOccurs and not exsi:is-arry (in the examples only the presence or absence of unbound is used, so it cold be replaced by a boolean)

I think that, independently of JSON arrays, defining exsi:maxOccurs and exsi:minOccurs might be useful to limit items editing within repeat. There is no xsd:is-array, BTW.

·         I don’t like the '________' it is hard to remember how many ‘_’ you have to type. Why not use something like ”exml:element” (better name is welcome)

This element has to be in the empty namespace as others for not disturbing the namespace-uri() and name() functions. Its name has to be improbable in JSON objects and shouldn't be typed. Better name is welcome, of course.

·         I don’t like the section ‘XPath Engine Proposed Enhancements’ because it makes requires you to change the core XPath engine. In my opinion this will do more harm than it does good, because the standard selectors and functions will behave differently if you are accessing a JSON instance and one xpath expression could access both native XML instances and JSON instances. I’m afraid this will be confusing for both novice and experienced XPath users. (we could maybe us json-name() instead of fullname() and maybe do some other small tweaks to make life easier (e.g.: json-node(‘a’)  returns the node with name ‘a’ in the current context, in XPath 2.0 one can then write json-node(‘a’)[2] or json-node(‘a’)/ b/ json-node(‘1234’).

This should not be limited to JSON. vCard is interesting too, CSV wouldn't be difficult to integrate either and so on. That's why I banished names starting with "json-".

I really think that the single document element restriction in XML 1.0 is a very bad idea and I hope that next versions of XML will allow multiple roots. That's why I'm using "exml:noname" as a dummy element : it's a name to be recognized as a special one due to XML 1.0 limitations. I think the instance() function is more confusing comparing it with document() or doc() functions. As you say, the default context is already at the document element which is disturbing when used to XPath evaluation from other languages.

Calling a function within a path is not permitted in XPath 1.0 and, for performance, I consider that a function call is more time consuming whereas this can be interpreted,  once for all, at parsing time.

I understand that some implementations are based on external XPath engines not allowing to improve the core syntax but just to add external functions. XSLTForms (and, as far as I know, other client-side implementations written in Javascript) needs its own XPath engine. XPath was designed for XML only but there is not much to be added to allow using it with other notations.

Thanks!

-Alain
Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

Erik Bruchez
In reply to this post by John Boyer
Got it.

Our implementation does an exact match, whether the value is empty or not.

It seems a bit odd to me to make empty value behave differently from any other value, and I could bet that the default expectation for a form author would be to assume that, if an empty value is legal for an itemset value, then it should match an empty value in instance data.

-Erik

On Wed, Dec 15, 2010 at 9:43 AM, John Boyer <[hidden email]> wrote:

Hi Erik,

Quick notes:

1) The poll is not about the question you answered in this email.  I think we pretty much answered the original question with the "exact string match" behavior that you use everywhere except on initial load, so adjusting your initial load to be a string match without trimming would be best considering the answer we sent out already.

2) The poll question is asking what happens to a select1 when the ref of the select1 binds to a node with empty content and the select1 contains an item whose value is empty.  To make it easy, say you use appearance="full" so that you get a radio button group.  Let the item with the empty value be the middle of three item elements in the select1.  Does the radio group show no items selected or does it show the middle item as selected?

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Erik Bruchez <[hidden email]>
To: [hidden email], Forms WG <[hidden email]>
Date: 12/14/2010 11:20 PM
Subject: Re: Implementors please read: poll about select1 and empty values





All,

I haven't yet had time to fully dig into this, but our implementation
seems to trim strings on both sides before comparison, but only on
initial show of the page to indicatedthe initially-selected item. That
would be a bug!

Other than that, the Orbeon behavior is to do an exact string match
with select1 (as pointed out, it doesn't for select).

(BTW Leigh, I can't seem to run your test case page right now.)

-Erik

On Wed, Dec 8, 2010 at 10:09 AM, Leigh L. Klotz, Jr.
<[hidden email]> wrote:
> A question has come up about conformance and interoperability of XForms
> processors with regard to the behavior of select1 when a value is the empty
> string or whitespace only.
>
> This message is a poll to find out how select1 with an empty item/value
> element behaves in existing XForms 1.1 implementations.  Based on the
> results of this poll we may add additional test cases, additional
> clarification, issue an erratum, or propose new features for XForms 1.2.
>
> Background:
> The XForms 1.1 Recommendation says [1] about select1 (and select as well):
>
>
> "For both closed and open selections, any selection item with a storage
> value which is empty or which contains only white space characters must
> remain deselected."
>
> Discussion:
> Nick van den Bleeken tentatively reported that least one implementation
> supports a select1/item/label for the empty item/value.
>
> John Boyer and I both noted that select has this implementation requirement
> because its space-separated values in list content are indistinguishable
> from empty.  In short, the absence of any selected item is ithe indication
> that no item is selected.
>
> John further noted, however, that the requirement on select1 is motivated
> not only by consistency with select, but also by another point, that the
> "required" MIP be used to indicate that a value has been set.  John noted
> that xsi:nil can also be used for this purpose, but is not well understood
> or implemented.
>
> John suggested to form designers that a "none" value for any select1
> control-bound data would better be represented by a distinguished value
> chosen by the application, e.g. "none" or "n", rather than an empty value.
>
> I noted that only if the XForms application and the data are co-designed can
> the form designer can satisfy this requirement, and that web resources may
> require an empty string to indicate a value of "none," and that allowing a
> binding of a label gives form designers the ability to express this UI.
>
> As a result of this discussion, we are polling implementations and seeking
> feedback on the presentation and behavior of empty ref node values and empty
> item/value (and by extension, itemset) in select1.
>
> Test Case:
>
> I have produced a test and made it work using xsltforms.
> It is available at
http://xformstest.org/2010/12/select1-empty and please
> choose select1-empty.xml
> We're asking implementors to adapt and run this test case and report
> behavior.
> A sample report is below:
>
> Test Case Results Example
> For the sample I produced, here are the results for the select1 cases with
> an empty item/value.
> (The test page also includes controls with no empty item/value).
>
> no appearance:
> displays as pulldown menu
> empty value displays as a blank item inside select1. (to spec)
> selecting the "(empty)" labeled item causes only that control to change.
> (partially to spec)
> after that, selecting the unlabeled item causes all form controls bound to
> the node to change to the "(empty)" labeled item (not to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains.
> selecting the "(enpty)" labeled item again causes the blank item to
> re-appear in all select1 controls (???)
>
>
> appearance=minimal:
> displays as pulldown menu
> same behavior as above
>
> appearance=compact
> displays as in-place visible menus with one selection allowed
> same behavior as above
>
> appearance="full"
> displays as radio buttons; no blank or unlabeled radio button
> empty value displays as a selected "(empty)" radio button. (NOT to spec)
> selecting the "(empty)" labeled item causes all form controls to change to
> display the unlabeled item. (to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains;
> selecting the "(empty)" labeled item again causes the blank item to
> re-appear in all select1 controls. (???)
>
> Of the above, only the full appearance (radio) had a notable behavior: it
> offered no way to choose the empty item, and if the empty item were chosen
> by another control, it displayed with no selection.
>
> Leigh.
>
>
> [1]
http://www.w3.org/TR/xforms11/#ui-selectOne




Reply | Threaded
Open this post in threaded view
|

Re: Implementors please read: poll about select1 and empty values

John Boyer

Cool, OK so that's at least two XForms implementations then that match empty string in a select1 ref to an item with an empty string value, if one exists.

Leigh and Steven, can we discuss creating an XForms 1.1 erratum for this?

Thanks,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Erik Bruchez <[hidden email]>
To: Forms WG <[hidden email]>, [hidden email]
Date: 12/21/2010 07:14 PM
Subject: Re: Implementors please read: poll about select1 and empty values





Got it.

Our implementation does an exact match, whether the value is empty or not.

It seems a bit odd to me to make empty value behave differently from any other value, and I could bet that the default expectation for a form author would be to assume that, if an empty value is legal for an itemset value, then it should match an empty value in instance data.

-Erik

On Wed, Dec 15, 2010 at 9:43 AM, John Boyer <boyerj@...> wrote:

Hi Erik,


Quick notes:


1) The poll is not about the question you answered in this email.  I think we pretty much answered the original question with the "exact string match" behavior that you use everywhere except on initial load, so adjusting your initial load to be a string match without trimming would be best considering the answer we sent out already.


2) The poll question is asking what happens to a select1 when the ref of the select1 binds to a node with empty content and the select1 contains an item whose value is empty.  To make it easy, say you use appearance="full" so that you get a radio button group.  Let the item with the empty value be the middle of three item elements in the select1.  Does the radio group show no items selected or does it show the middle item as selected?


Cheers,

John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail:
boyerj@...  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw



From: Erik Bruchez <ebruchez@...>
To: [hidden email], Forms WG <[hidden email]>
Date: 12/14/2010 11:20 PM
Subject: Re: Implementors please read: poll about select1 and empty values






All,

I haven't yet had time to fully dig into this, but our implementation
seems to trim strings on both sides before comparison, but only on
initial show of the page to indicatedthe initially-selected item. That
would be a bug!

Other than that, the Orbeon behavior is to do an exact string match
with select1 (as pointed out, it doesn't for select).

(BTW Leigh, I can't seem to run your test case page right now.)

-Erik

On Wed, Dec 8, 2010 at 10:09 AM, Leigh L. Klotz, Jr.
<
Leigh.Klotz@...> wrote:
> A question has come up about conformance and interoperability of XForms
> processors with regard to the behavior of select1 when a value is the empty
> string or whitespace only.
>
> This message is a poll to find out how select1 with an empty item/value
> element behaves in existing XForms 1.1 implementations.  Based on the
> results of this poll we may add additional test cases, additional
> clarification, issue an erratum, or propose new features for XForms 1.2.
>
> Background:
> The XForms 1.1 Recommendation says [1] about select1 (and select as well):
>
>
> "For both closed and open selections, any selection item with a storage
> value which is empty or which contains only white space characters must
> remain deselected."
>
> Discussion:
> Nick van den Bleeken tentatively reported that least one implementation
> supports a select1/item/label for the empty item/value.
>
> John Boyer and I both noted that select has this implementation requirement
> because its space-separated values in list content are indistinguishable
> from empty.  In short, the absence of any selected item is ithe indication
> that no item is selected.
>
> John further noted, however, that the requirement on select1 is motivated
> not only by consistency with select, but also by another point, that the
> "required" MIP be used to indicate that a value has been set.  John noted
> that xsi:nil can also be used for this purpose, but is not well understood
> or implemented.
>
> John suggested to form designers that a "none" value for any select1
> control-bound data would better be represented by a distinguished value
> chosen by the application, e.g. "none" or "n", rather than an empty value.
>
> I noted that only if the XForms application and the data are co-designed can
> the form designer can satisfy this requirement, and that web resources may
> require an empty string to indicate a value of "none," and that allowing a
> binding of a label gives form designers the ability to express this UI.
>
> As a result of this discussion, we are polling implementations and seeking
> feedback on the presentation and behavior of empty ref node values and empty
> item/value (and by extension, itemset) in select1.
>
> Test Case:
>
> I have produced a test and made it work using xsltforms.
> It is available at
http://xformstest.org/2010/12/select1-empty and please
> choose select1-empty.xml
> We're asking implementors to adapt and run this test case and report
> behavior.
> A sample report is below:
>
> Test Case Results Example
> For the sample I produced, here are the results for the select1 cases with
> an empty item/value.
> (The test page also includes controls with no empty item/value).
>
> no appearance:
> displays as pulldown menu
> empty value displays as a blank item inside select1. (to spec)
> selecting the "(empty)" labeled item causes only that control to change.
> (partially to spec)
> after that, selecting the unlabeled item causes all form controls bound to
> the node to change to the "(empty)" labeled item (not to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains.
> selecting the "(enpty)" labeled item again causes the blank item to
> re-appear in all select1 controls (???)
>
>
> appearance=minimal:
> displays as pulldown menu
> same behavior as above
>
> appearance=compact
> displays as in-place visible menus with one selection allowed
> same behavior as above
>
> appearance="full"
> displays as radio buttons; no blank or unlabeled radio button
> empty value displays as a selected "(empty)" radio button. (NOT to spec)
> selecting the "(empty)" labeled item causes all form controls to change to
> display the unlabeled item. (to spec)
> selecting the "full" labeled item causes all controls to change to "full".
> (to spec)
> selecting the "full" labeled item causes the blank item to disappear from
> all select1 controls, however the explicit "(empty)" choice remains;
> selecting the "(empty)" labeled item again causes the blank item to
> re-appear in all select1 controls. (???)
>
> Of the above, only the full appearance (radio) had a notable behavior: it
> offered no way to choose the empty item, and if the empty item were chosen
> by another control, it displayed with no selection.
>
> Leigh.
>
>
> [1]
http://www.w3.org/TR/xforms11/#ui-selectOne