XML for forms

[Trevor Croll]

I was looking at writing an application which interprets XML for general
distribution - the purpose is filing of forms data. (Many peculiar
requirements exist where record keeping is required with computer ability to
search and analize data quickly.) I was looking at writing a tool set for
servicing these peculiar requirements using XML
Is this feasible?


I have looked at Xpointer and Xlink but do not fully understand if these can
be used to pull data into a XSL form from a XML data base for display
purposes and put changed data back.

Is XML good enough to be able to provide a data structure for storing raw
data and using XSL display the data in its many views that would be required
in an office like application )customer notes, mail merge, appointments,
todos. calendar, invoices etc..... ie a filing system of XML forms where the
data is kept for all records and a view is kept once for each view of the
data.

Is what I'm looking at a reasonable thing to be looking at XML for even if I
will write the whole thing myself perhaps even adding some pecularities to
the language to produce a result?


----- Original Message -----
From: Marcus Carr <mrc at allette.com.au>
To: Trevor Croll <litebook at powerup.com.au>
Cc: <xml-dev at ic.ac.uk>
Sent: Thursday, July 01, 1999 11:10 AM
Subject: Re: XML for forms


>
> Trevor Croll wrote:
>
> > To me it appears that XML offers the programmer a much more
> > sophisicated data structure than any previously imagined. A well
> > structered symble table of variables seems to offer the programmer a
> > much better easier applications building approach BUT there is a
> > tangle of data and screen markup like <font "size = 10"> and form
> > details like the letter head etc.. which is not data and not
> > interesting to the applications programmer, only of interest to the
> > viewer. How would one keep real data separate from display markups and
> > screen text words like "INVOICE" etc????
>
> One way would be to use something like Acrobat Forms from Adobe. They
> allow you to define value pairs, which are a named field and a value.
> You can create a PDF form with blank spaces for entering data.
> Submitting the form allows you to obtain the value pairs alone, without
> making you sort through the extras you would have to deal with in an
> HTML form. The opposite is also possible - you can merge a PDF form with
> value pairs, making it possible to display the data as you deem
> appropriate.
>
> Although this isn't yet an XML solution, my understanding is that XML
> support is planned for Acrobat. Also, the conversion between the syntax
> used for value pairs and XML is trivial, so it could be considered to be
> a delivery mechanism at the back end of an XML system.
>
>
> --
> Regards,
>
> Marcus Carr                      email:  mrc at allette.com.au
> ___________________________________________________________________
> Allette Systems (Australia)      www:    http://www.allette.com.au
> ___________________________________________________________________
> "Everything should be made as simple as possible, but not simpler."
>        - Einstein
XML seems to be devoted to putting data markup into documents so programs,
like search engines, can understand the content on those documents. But what
of forms processing?

Lets say we had a DTD with a list of data conforming to the DTD (many data
items). This data could represent a name file with lots of customer name and
contact information. The form could be a letter for that data to be merged
into. The DTD is designed to represent the customer name file data.

ie       DTD defining field details in customer Name file

Name file data
<FirstName> Fred </FirstName> <Surname>Bloggs</Surname>
<Address1>123 some street</Address1> <Suburb>Some Suburb</Suburb>
<Town>Bunyip</Town> <State>Victoria</State>  <PostCode> 4100   </PostCode>
<Country>Australia</Country>

<FirstName>Brian </FirstName> <Surname>Browns</Surname>
<Address1>Another street</Address1> <Suburb>Another Suburb</Suburb>
<Town>Drouin</Town><State>Victoria</State> <PostCode> 4100   </PostCode>
<Country> Australia</Country>

Document XSL

Litebook Computers P/L    (letter head etc.......)

    <FirstName> <Surname>
    <Address1>
    <Suburb> <State> <PostCode>
    <Country>

Dear <FirstName>
    As you have probably heard in the media XML is the comming standard for
Internet but how will it work for other functions like mail merge, document
interchange such as invoices, statements order form processing from company
to company - accounting system to accounting system?

Does every accounting system have to store its data in relational or other
structure and do a transformation to XML or can the accounting system store
its data in XML format, even though it might not be as efficient a data
storage method.
-------------------------------------
There are parallel data storage formats PICK uses an attribute marker for
data storage and so can have a storage structure which is a linited syntax
tree
Attribute marker characters are chars 255, 254, 253
Eg:
customer name | address 1 | Suburb | State | Postcode | Invoices | 12312312/
1233423 / 455664 / 464646 / 46456 / 786886 / 77669 / 8790890 / 8908008/ ~
where | is char 254 and / is char 253 ~ is char 255 (end of record)
This structure allows pick programmers to store a unlimited list of invoice
numbers in the customer's record.
-------------------------------------
Another data structure type is MUMPS where the storage unit is unique key =
Data item,

The key is a sparse array eg  Global  ^Debtors would have

^Debtors(ShortName, Litebook, Inv 123) = "123 | 25/12/90 | $230.00 | $23.00
|"
^Debtors(ShortName, Litebook, Inv 123, item1) = "Sof123 | Software program
for parsing XML | 1only | $220.00"

MUMPS has a $piece function string = $P(^Debtors(ShortName, Litebook, Inv
123, item1) ,"|",2)
would yeild string = "Software program for parsing XML"
-------------------------------------
To me it appears that XML offers the programmer a much more sophisicated
data structure than any previously imagined. A well structered symble table
of variables seems to offer the programmer a much better easier applications
building approach BUT there is a tangle of data and screen markup like <font
"size = 10"> and form details like the letter head etc.. which is not data
and not interesting to the applications programmer, only of interest to the
viewer.

How would one keep real data separate from display markups and screen text
words like "INVOICE" etc????




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)