W3C home > Mailing lists > Public > www-forms-editor@w3.org > January 2002

conformance levels in XForms

From: joern turner <joern@webman.de>
Date: Mon, 28 Jan 2002 18:01:45 +0100
Message-ID: <3C5583F9.7030405@webman.de>
To: www-forms-editor@w3.org
Hello all,

former discussion on the mailinglist lend to the introduction of an 
additional conformance-level called 'Basic'.

But from my experience as an implementor of XForms it's my honest 
belief, that there should be another conformance level below 'Basic' 
which i call 'pragmatic' as a working title.

This should only contain the features that are absolutely necessary to 
build a functional form-processor.

why should this be introduced? simply cause even a very basic 
(pragmatic) implementation would help to *greatly* improve current 
custom form-processing problems and open a migration path from web-forms 
to full XForms.

let me describe the requirements which i consider the mimimum level:
- support of all XForms controls including group, repeat, switch.
- support for xforms:required plus support for pattern-validation 
(possibly via isValid)
- support for namespaces

i think even this reduced list will be sufficient to many applications 
today and even brings some additional gain to them.
What basically is needed today may be summarized under following points:
- i need defined datastructures as output of a form-session
- i need completeness of data (via required)
- i like to have repeating structures (a real pain with web-forms)
- i like to have full XML support (therefore namespace support)
- i need to validate that my sring-data conform to some pattern. This 
allows to test values which otherwise need datatyping (e.g. dates)

- no support for datatypes except String
- no support for Schema validation
- no support for multiple forms
- no XForms functions
- no specific event-handling (means: implementor is free to decide how 
to solve this)
- no support for Xlink (load only complete containers with inline model 
and instance-data)
- no requirements which need an XPath implementation

why would i like to exclude these from a 'pragmatic' conformance level?
some arguments:
- support for schema-validation and datatyping is still 'bleeding edge'; 
the current available implementations are not feature-complete or cause 
performance or integration problems. So, this area needs a lot of work 
and testing. Requiring this in a Basic processor prevents that XForms 
implementations appear quickly.
- most current systems do not need multiple forms cause they've learned 
to live with the constraints of web-forms and have tailored their forms 
to use only one per page (not a clean conceptual argument but a 
pragmatic one)
- resolving XLinks requires to implement an external interface for your 
implementation which may cause a lot of effort. The same would also be 
achievable by resolving this externally and putting a complete document 
into the processor

Thanks for considering this issue


Joern Turner
Received on Monday, 28 January 2002 12:02:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:38:05 UTC