XML and (K)Office
James Robertson
jamesr at steptwo.com.au
Thu Mar 25 22:22:32 GMT 1999
At 21:55 25/03/1999 , David Megginson wrote:
| [David]
|
| > > Anyway, let's get this right -- I think that it's healthy for
| > > both Gnumeric and the KOffice Spreadsheet program both to exist,
| > > but there is no excuse for them to use entirely incompatible
| > > formats. As a matter of fact, if we could convince KDE and Gnome
| > > to use compatible XML formats for lots of things (like interface
| > > construction), the media's predictions of a Linux fracture will
| > > be proven to be hot air.
|
| [Matt]
|
| > Although I agree to an extent, if they have different feature sets
| > it's pretty unlikely that you're going to get an entirely perfect
| > agreement on a spreadsheet DTD.
|
| I disagree *very* strongly -- with Namespaces, we can design a common
| format for the 90% of functionality that the two spreadsheets actually
| have in common (text cells, data cells, basic formulas, general
| formatting information [font, alignment, colour, size], etc.) and
| then allow each to provide extended information
| unambiguously-delimited through the use of separate namespaces.
|
| The more material in the common spec, the better interoperability.
| Linux needs to set an example here.
Why do namespaces help us here?
It:
* Breaks validation. We are no longer able to ensure that the
files we are reading/creating are correct and useful.
* Still has the variations between applications, so that a reader
of a given format still needs to know 100% about what is that
format.
Without the rigour of a DTD, we've got nothing.
Particularly since this data may well live long, and is not
some transient "sent over the web" data.
How will future users make sense of the format without
a DTD?
| > However, that's the beauty of XML. Writing a converter from one
| > format to another is trivial in the extreme, so it's not a huge
| > issue in my (humble) opinion.
|
| For n XML-based formats, we need (n * (n - 1)) converters. If there
| are only two different XML-based spreadsheet formats, then we need
| only two converters:
|
| a => b
| b => a
|
| If there are three XML-based different formats, then we need six
| converters:
|
| a => b
| a => c
| b => a
| b => c
| c => a
| c => b
Again, having namespaces doesn't solve this problem. Regardless
of what you call it, if the formats are different, they're different.
But anyway, this reasoning isn't necessarily true. What about:
a => x
b => x
c => x
x => a
x => b
x => c
That is, an intermediate DTD that captures all the usefully
sharable data. For a successful example of this, see the
Rainbow DTDs for word documents.
This greatly reduces the number of conversions as the
number of formats increases.
Cheers,
James
-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr at steptwo.com.au
"Beyond the Idea"
ACN 081 019 623
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