FW: XForms - how easy is maintenance?

this form of documentation might well be useful --but given the
architecture of XForms, there is nothing that prevents you from doing
it today --you can stick as much documentation as you want in the
instance, and as long as you dont bind a control to it no one will see
it.
It would probably turn out to be suboptimal since you would then end
up carrying the documentation along with the instance, which is why
you may want to instead put it in the schema --or whatever your
favorite schema language du jour is.
>>>>> "Ben" == Ben Nolan <ben@ripcord.co.nz> writes:


    Ben> I was thinking along the lines of:

    Ben> XML: <doc> <fruit>banana</fruit>
    Ben> <phone>+6421-210-1234</phone> </doc>

    Ben> SCHEMA: <doc> <fruit type="enum"
    Ben> value="banana|orange|apple"/> <phone type="pattern"
    Ben> value="\+\d{4}-\d{3}-\d{3,}"/> </doc>

    Ben> Looking up datatype from an XSD is pretty expensive to do in
    Ben> javascript.

    Ben> Regards, Ben

    Ben> -----Original Message----- From: JOHANSSON, Justin
    Ben> [mailto:Justin.JOHANSSON@baesystems.com] Sent: Wednesday, 12
    Ben> March 2003 2:07 p.m.  To: 'Ben Nolan'; www-forms@w3.org
    Ben> Subject: RE: XForms - how easy is maintenance?


    Ben> Picking up on Ben Nolans observation

    Ben> "functionality back to schemas (and possible a new form of
    Ben> schema that isn't so bloody hard to parse) would make xforms
    Ben> more applicable to real-world situations."

    Ben> In my (personal) opinion, such a schema already exists.

    Ben> It's called RELAX NG.

    Ben> FFI, see "the next generation schema language for XML: clean,
    Ben> simple and powerful."

    Ben> http://www.oasis-open.org/committees/relax-ng/

    Ben> Regards,

    Ben> Justin Johansson Intranet Developer South Australia




    Ben> -----Original Message----- From: Ben Nolan
    Ben> [mailto:ben@ripcord.co.nz] Sent: Wednesday, 12 March 2003
    Ben> 11:09 To: AndrewWatt2001@aol.com; www-forms@w3.org Subject:
    Ben> RE: XForms - how easy is maintenance?



    Ben> /quick-rant-mode on

    Ben> I have similair worries, in my particular instance (financial
    Ben> data gathering) - I am trying to absolutely minimize the
    Ben> amount of logic and layout in the xforms/xhtml pages.

    Ben> One way I'm thinking of approaching this is to do away with
    Ben> select1/select/etc - and use only the <input/> element - with
    Ben> the display of the field entirely dependent on the datatype
    Ben> of the ref'd data - and the appearance attribute. Eg -
    Ben> enumerated datatypes are listed as a (dropdown|checkboxes) -
    Ben> depending on the appearance attribute.

    Ben> I do data-type constraints at xforms-deactivate time, and
    Ben> validation for the included inputs (only !null at this stage)
    Ben> at xforms-submit time.

    Ben> I'm very new to xforms and xml and haven't had time to
    Ben> totally get my head around the best way to do things - but I
    Ben> think tying a lot more functionality back to schemas (and
    Ben> possible a new form of schema that isn't so bloody hard to
    Ben> parse) would make xforms more applicable to real-world
    Ben> situations.

    Ben> I fear xforms will rapidly degenerate into a cross-browser
    Ben> javascript type mess otherwise.

    Ben> Regards, Ben Nolan

    Ben> Ripcord Technology

    Ben> -----Original Message----- From: www-forms-request@w3.org
    Ben> [mailto:www-forms-request@w3.org] On Behalf Of
    Ben> AndrewWatt2001@aol.com Sent: Tuesday, 11 March 2003 5:46 a.m.
    Ben> To: xforms@yahoogroups.com; www-forms@w3.org Subject: XForms
    Ben> - how easy is maintenance?



    Ben> I guess ease of maintenance is a little in the eye of the
    Ben> beholder.

    Ben> As I work with XForms-containing code it seems to me that
    Ben> XForms, with its binding between different parts of the code
    Ben> and the potential for event-processing code to be widely
    Ben> separated in large pages, has the potential to create many
    Ben> maintenance difficulties.

    Ben> It reminds me of the tangle that early forms of JavaServer
    Ben> pages could produce once they moved beyond the
    Ben> trivial. Obviously the issues aren't identical.

    Ben> It seems to me that XForms has similar potential to be less
    Ben> than easy to

    Ben> maintain.

    Ben> Have others been considering this issue? Any thoughts about
    Ben> approaches which can minimise the likely problems?

    Ben> Andrew Watt

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
AIM:      TVRaman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Wednesday, 12 March 2003 15:37:27 UTC