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