OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: XML and (K)Office

[ Lists Home | Date Index | Thread Index ]
  • From: James Robertson <jamesr@steptwo.com.au>
  • To: "XML Developers' List" <xml-dev@ic.ac.uk>
  • Date: Fri, 26 Mar 1999 09:20:58 +1000

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?


* 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
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.



James Robertson
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:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS