Lists Home |
Date Index |
- From: James Robertson <firstname.lastname@example.org>
- To: "XML Developers' List" <email@example.com>
- Date: Fri, 26 Mar 1999 09:20:58 +1000
At 21:55 25/03/1999 , David Megginson wrote:
| > > 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.
| > 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?
* 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
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
| > 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
| 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.
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
"Beyond the Idea"
ACN 081 019 623
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)