Lists Home |
Date Index |
- From: Thierry Bezecourt <firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 01 Aug 2000 19:44:04 +0200
At 11:36 01/08/2000 -0500, Imran Rashid wrote:
> > 1/ I agree with the first step: use XSLT to transform a waggaziggyML
> > document into an OfficeML document. I already do something similar by
> > applying an XSLT stylesheet to an XML source to generate an RTF
> > documentation. A well-documented, "standard" OfficeML would be useful
>though I could use XSLT to transform my document to RTF, I think thats
>several orders of magnitude harder than transforming to some other ML. I
>believe other XML developers have a very similar attitude.
I agree (although RTF is less hard than it seems at first glance; cutting
and pasting unreadable formatting instructions from sample Word-RTF files
to your XSLT stylesheet works surprisingly well.)
> > The target software would have to support so many things that it
> > would be more simple for it to support OfficeML directly. This is what most
> > word processors do already by supporting RTF.
>I would be much more inclined to add support for RTF if I could use my
>existing XML parser, than having to add a whole new RTF parser. adding
>support for OfficeML is something we could do incrementally, but adding
>support for RTF would be a large undertaking we would have to be committed
The more we discuss this, the more I feel that OfficeML may (or should) be
functionally equivalent of RTF, and there could be a 1:1 mapping between
RTF formatting instructions (or bracket) and XML tag. The advantage of
OfficeML vs RTF would be syntax: XML is more readable than RTF, and there
more ways to parse it. You could still implement or support OfficeML gradually.
> > Or maybe the target software does not really want to display the entire
> > Word document, but only to extract and display some specific data in your
> > document. But how will you extract useful data from an OfficeML
> > document? The problem here is that Word (and thus OfficeML) does not
> > separate data from presentation.
>though Word doesn't seperate data from presentation, users can do things in
>reasonable ways that still make data evident. For instance, emphasis should
>be added by using an emphasis style, instead of just making text bold. or
>using tables over tab-delimited text.
> everything won't be perfect, but I think OfficeML will be a big step
It seems reasonable, if you accept to spend time on testing the results
each time you add new kinds of XML sources or applications.
> > Of course,
> > you could create "islands" in your document to store additional
> information :)
>actually, I don't really think data "islands" are that bad an idea. (of
>course we wouldn't use the reserved "xml" name.) for instance, suppose
>somebody wants to create a document that uses MathML as well as VoiceML.
>Someone might turn to our program to author the MathML, and another program
>for the VoiceML. But it would be nice if after creating the VoiceML, they
>could save their document and open it up in our program. They could embed
>the VoiceML data in some container tag (which our program knows it should
>leave untouched), edit the MathML, and save again.
Wouldn't you use namespaces to do that?