[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML and (K)Office

• From: James Robertson <jamesr@s...>
• To: "XML Developers' List" <xml-dev@i...>
• 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?

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@s...

"Beyond the Idea"
 ACN 081 019 623

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • RE: XML and (K)Office
    • From: David Megginson <david@m...>

• References:
  • RE: XML and (K)Office
    • From: "Matthew Sergeant (EML)" <Matthew.Sergeant@e...>
  • RE: XML and (K)Office
    • From: David Megginson <david@m...>

• Prev by Date: Re: Whence XQL?
• Next by Date: Re: XML and (K)Office
• Previous by thread: RE: XML and (K)Office
• Next by thread: RE: XML and (K)Office
• Index(es):
  • Date
  • Thread