- From: joern turner <joern@webman.de>
- Date: Mon, 28 Jan 2002 18:01:45 +0100
- 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) but: - 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 Regards Joern Turner
Received on Monday, 28 January 2002 12:02:13 UTC