All this buisiness about namespace URNs...

Carl Hage carl at chage.com
Thu Jun 3 20:16:17 BST 1999


From:           	"Daneker, Vincent" <DanekerV at visa.com>

> So, the development of XML aware applications seems to be a logical step.
> Currently, IE5 can display raw XML, which isn't particularly appealing,
> but it can be done. Will Excel or Access in Office 2000 (or tools by any
> other company, MS is just an example, please don't flame me) allow direct
> and sensible import of an XML file into their formats?

Thanks for bringing things back to reality-- that's the whole point of 
XML (it's not really a scheme to force purchase of upgrades).

Besides general office software, sensible import into applications like 
Quicken will also be important.

In order for import to be sensible, the application software needs to be 
able to interpret the format and semantics (to a certain degree) for 
each tag read. That means the application needs to get more 
information than just the syntax of the DTD.

The URI's referenced in the XML headers and DTD are a natural way for 
applications to access the information needed for a sensible import, 
and as a sensible means for humans to access the documentation 
about the data.

After you load an XML file into a spreadsheet, database, or XSL 
transformed data entry form, you want the "Help" button to work 
properly and directly show the definition of that data. You don't want to 
write to Geneva and buy a $900 document, or track down a 
programmer to find the meaning of a field.

> The blind exchange of data in e-commerce could open a can of worms.
> However, if I'm engaged in a commercial venture, then I'm going to ensure
> that you, our valued customer, have everything you need from us to
> complete your transaction. 

Unfortunately, that's not the norm. Missing or ambiguous 
documentation and missing code values is quite common. For every 
vendor or customer, the software is modified since the "standards" 
aren't really standards.

Data exchange these days is often in fixed length files (it's hard to get 
mainframe programmers to create tab-delimited), where the postal-
mailed data file is accompanied by a paper containing the 
documentation-- a list of abbreviated field names with columns. You 
retype all the columns into a computer (or scan and OCR the paper, 
then write a perl program to extract the record format). In about 40% of 
the cases, the documentation has errors. When you don't understand 
the field name semantics, you call the owner of the data, and often, 
they have no idea either.

XML could be a continuation of the nightmare, since it allows any writer 
of data to invent a new DTD. Data should be written so it can be 
imported (not just exported), meaning it must be transformed into 
some agreed upon standard which can be interpreted.

XML today is incrementally better than the usual fixed-length flat file 
with faxed record format in that it at least has an electronic definition of 
the syntax of the data. In my opinion XML won't be significant until all 
data that exists has associated electronic definitions of the semantics 
as well as syntax.

Style sheets that print the data are incomplete-- there needs to be 
style sheets to print the documentation of the data as well, e.g. so the 
context sensitive help in a data entry form functions properly.

Likewise, if I type a value into a form from a controlled vocabulary, e.g. 
"California" or "CA", the spreadsheet or browser should be able to 
access the CV definitions to validate that entry, without having to 
create/modify software, download some Java (that works in only 1 
application), etc.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl at chage.com> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

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)





More information about the Xml-dev mailing list