Re: How xforms 1.1 handles elements with xsi:nil set to true. (Integration between XBRL and XFORMS)

Hi Ignacio,

Actually Firefox is not broken at all.  The XML Schema nillable feature is 
really not too well designed for client-side interaction.  At XML 2007, I 
spoke with Michael Sperberg-McQueen about the seeming inconvenience of the 
nillable construct, and he told me that it was designed for some special 
case behavior of databases and that database experts would be able to 
elaborate.  I got the impression from him that DB experts wanted a way in 
the data to know whether empty string meant store an empty string or 
destroy a record, which means nillable has semantics that should be 
investigated more thoroughly before it is used.

The feature is of course usable in XForms, but it is you who has to make 
the feature work for you.  In general, XForms will not go into your data 
and destroy an attribute (like xsi:nil) in response to the end-user 
editing the value of a node with a form control.  Form controls change 
only the value of the node to which they are bound, as per Chapter 8 UI 
spec.

However, it is not necessary to remove the xsi:nil attribute, but only 
that it should be true when the element is empty and false when the node 
is non-empty.

So, all you need to do is add a calculate like the following:

<bind nodeset="Revenue/@xsi:nil" calculate="if(..='', 'true', 'false')" />

Furthemore, you can make all xsi:nil attributes behave this way by 
changing the nodeset of the above bind to identify all xsi:nil attributes 
in instance data, like this:

<bind nodeset="//@xsi:nil" calculate="if(..='', 'true', 'false')"/>

This creates the calculate formula once for every xsi:nil in the default 
instance tree.  You may have multiple instances to deal with, in which 
case you have to do a bit more work on the above nodeset, but hopefully 
you get the idea. 
Finally, note that a schema may indicate that something is nillable, but 
that does not mean you have to use the feature.  It's generally not a good 
idea to infest your data with type information.  The xsi: attributes are a 
hack because they mix the two layers of information based on not really 
having a better answer at the time.  XForms provides that better answer, 
allowing you to express concepts like 'type' and 'required' with model 
item properties. 

I realize that you don't have full flexibility to take advantage of this 
situation because you are implementing an integration to XBRL, so you are 
more likely to want to use a schema.  However, even in this case, you can 
at least consider using alternative features of schema to indicate that 
something can be empty.  For example, I think the problem you are trying 
to solve is that xbrli:monetaryItemType is the datatype you want to 
validate against *once the user has actually entered some data*, but that 
you don't want to flag an error on empty string because the user has not 
entered any data yet.  Rather than using nillable in your schema, you 
could simply define a new type that is a simple union between empty string 
and xbrli:monetaryItemType.  In fact, the XForms 1.1 schema defines just 
such types for all basic XML schema datatypes for you, so you can look at 
the XForms schema to see how it is done.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

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






From:
Ignacio Hernández-Ros <ignacio@reportingstandard.com>
To:
<www-forms@w3.org>
Cc:
<public-forms@w3.org>
Date:
05/27/2008 04:23 AM
Subject:
How xforms 1.1 handles elements with xsi:nil set to true. (Integration 
between XBRL and XFORMS)



Hello,
 
First of all I would like to say thank you to all people suggesting to use 
CSS as the technology for take control over formatting issues of the form. 
This is working well and I’m making some progress that you can see here. 
http://www.reportingstandard.com/xforms/index.xhtml (you must open this 
page using a XForms aware browser. Content type is application/xhtml+xml 
and IE sometimes does not handle this properly).
 
I’ve a question about how the xforms spec (1.1) handles elements with 
xsi:nil set to true.
 
If I’ve an element definition in a schema like this:
 
<xsd:element 
name="Revenue" 
id="tx_Revenue" 
type="xbrli:monetaryItemType" 
substitutionGroup="xbrli:item" 
nillable="true" 
xbrli:periodType="duration"/>
 
then, an instance document according to this schema may contain an element 
like this:
 
<Revenue … xsi:nil=�true�/>
 
If I use a node like this in a xf:model and I bind a form control to the 
Revenue element. I would expect that if I type data in the form the 
generated XML document would contain something like
 
<Revenue … >1000</Revenue> 
 
That is; without the xsi:nil attribute on it because it has been “edited� 
to contain data. It looks to me that this is not “the default behavior” 
because I obtain 
 
<Revenue … xsi:nil=�true�>1000</Revenue> 
 
which is incorrect XML
 
This could also be a bug in Firefox so I’m sorry if this is the case. The 
reason I’m sending this to the w3c groups is because I’ve not read any 
implementation note in the xforms spec documentation about this. A 
normative sentence may not required, but it would be worth adding an 
implementation note.
 
 
Regards,
Ignacio
 
 
Ignacio Hernandez-Ros 
XBRL Expert
Reporting Estandar S.L.
ignacio@reportingstandard.com
xbrl.reportingstandard.com
Cell: +34 609027754