OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XML for forms

[ Lists Home | Date Index | Thread Index ]
  • From: Gavin McKenzie <gmckenzi@JetForm.com>
  • To: "'donpark@docuverse.com'" <donpark@docuverse.com>, Gavin McKenzie <gmckenzi@JetForm.com>, xml-dev@ic.ac.uk
  • Date: Mon, 5 Jul 1999 16:50:14 -0400


Don,

Yeah...I think it has probably been a year since we've last spoken.  Time
flies...I'm sure we've both been more than busy.

Your points are well taken, and appropriate.

I agree with your perspective on the value of using a modular approach based
upon best of breed implementation technologies to building solutions, and I
think that any developer of a new XML language would be served with starting
their efforts by understanding how they are going to achieve success in
light of such an approach.

However, forms are strangely complex objects that must rely upon some
combination of a dizzying array of technologies.  High-fidelity graphics,
text processing / document flow, scripting, navigation management, workflow,
data source integration, third-party software controls (ActiveX, Beans) etc.
etc.  Not all users/customers require all of these technologies -- a simple
web form may require very few.  A regulatory form in a complex workflow
terminating in the update of a database may require more.

Clearly, such a problem space is not served by trying to (re)invent so many
wheels.  But, it is well served by describing the high level abstraction or
model of a form and the framework within which you can use off-the-shelf
technologies as listed above.

The benefit should be that as the individual implementation technologies
change/improve/die that the overall abstraction or model should not change,
or at least change less than if it were based solely upon the bare
amalgamation of the technologies themselves.  It provides you a consistent
model which can be translated to the amalgam of implementation technologies
that are appropriate to you.

So yes...I agree with you...building non-monolithic solutions upon best of
breed implementation technologies (XHTML, SVG, XSLT) is viable, and IMHO
more successful when coupled with a modeling language that describes the
solution independent of any particular implementation.

Gavin.

> -----Original Message-----
> From: Don Park [mailto:donpark@quake.net]
> Sent: Monday, July 05, 1999 4:18 PM
> To: 'Gavin McKenzie'; xml-dev@ic.ac.uk
> Subject: RE: XML for forms
> 
> 
> Gavin,
> 
> Long time since I heard from ya <g>.
> 
> You are right that XFA/XFDL are not HTML and I am not arguing 
> that point.
> What I neglected to say was that the days of monolithic 
> standards are over
> and that we, the XML developers, should start adopting the 
> modular approach
> used in XHTML and XSL/XSLT.  Using this approach, XFA/XFDL can remove
> overlaps with XHTML modules and then divide up the remainder 
> into several
> modules.  Result would be far more understandable, supportable, and
> reusable.
> 
> Small, simple, modular XML standards is what I would like to see.
> 
> Best,
> 
> Don Park
> Docuverse
> 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS