XML for forms

[Trevor Croll]

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????








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990701/38556b47/attachment.htm