RE: [ubl-dev] Re: Input forms for UBL :: was "'Opensource' XForms for UBL"

[Chin Chee-Kai <cheekai@SoftML.Net>]

At 10:52 AM 2006-12-24 -0500, Andrew Schoka wrote:
>Chee-Kai,
>Maybe a third time would be a charm and particularly if you zipped the file
>and then did a .xxx as file extension.
>Regards,
>Andy Schoka

Andrew,
Thanks for the tip on zipping with ".xxx" extension.  Let me try it again as
per your suggestion.

The attachment's original extension should be ".zip".  So please rename it
before attempting to open.

[Come on, server, you gotta be more forgiving about attachments on 
Christmas Day...]



>Ps,  am intrigued by your approach and curious if it might be something to
>consider when I collaborate for our DOT Electronic Freight Management
>project.

There was some thinking put in to see which platform to initially focus our
development efforts on as far as data input is concerned.  There were a number
of angles that were looked at for the selection criteria.  But the more 
important
few points might be shared as follows:

- Learning curve issues: Most people are familiar with Excel, not just the 
file format,
   but the application, configurations, what works, what don't work and the 
corresponding
   work-arounds, and so on.  This makes it easier for people to reuse their 
knowledge
   about Excel, and quickly get on with business data entry, than to learn new
   technology and application.  In the implementation of electronic data 
systems,
   the input application is the "front line" ambassador that would greet or 
repel
   nervous users.  At least, it was thought, with something familiar as 
Excel, it would
   take away a layer of apprehension.

- Proprietary issues: Excel is only used during the data input phase.  While
   particular projects may choose to retain Excel as-is for source copy 
safe-keeping,
   it is not a mandatory file after the data is extracted by data extractor 
and stored
   in UBL or user-custom formats.  In other words, recipients can extract 
data from
   the XML version even when they do not have Excel installed.

- Cost issues: Cost per user might initially be seen as a down side for 
Excel vs, say,
   XForms.  But with some rather crude probabilistic estimates, we figure, 
firstly, that
   organisations or users would already have a version of Excel running, so 
implementing
   a data extractor to add additional functionalities to their "fixed cost" 
would increase
   leverage rather than incur more costs.

   Secondly, regardless of scale of implementation, the cost of adding 
Excel would
   constitute only a small portion of such electronic systems 
implementation, if the
   full cost of Excel cannot be used for other office purposes and must be 
borne solely
   by the project implementation costings (which is an extremely 
conservative assumption).
   The cost of training and supporting users to acquire use of other data 
input technologies
   might just end up exceeding the cost of installing an Excel on their 
desktops.


The above are not meant to give a conclusion that Excel-based input is the best
platform.  Individual circumstances might also necessitate other platforms 
other than
Excel.  But the points do tell us that it is a better way of letting 
general users input
data, at least for now.  XForms could be the next alternative input methods
to be implemented and supported in a complementary way.  With efforts like
those started by Stephen Green, it may be sooner than later that XForms reaches
a level at which it would be strategic to include XForms as another input 
platform in
project implementations.  So I'm keeping a lookout on that front as well.




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/