xml-dev - Re: XML in Office 200X

[Imran Rashid <imranr@wolfram.com>]

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

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.

> 2/ But I have my doubts as to the second step (conversion from OfficeML to
> another ML), because OfficeML would be very large.  The DTD would probably
> contain hundreds of element declarations.  To write a *generic* XSLT
> stylesheet to convert OfficeML to OogaML, you would need to write a
> template for each formatting feature in Word.

this is true, and it wouldn't necessarily be that easy.  But because of the
ubiquitousness of Office, I can guarentee you that my company would devote
the time and resources neccessary to come up w/ stylesheets that convert to
*and* from OfficeML, which we'll give to our users.  I'd bet money that most
other companies would too.
    in a way, I'm proposing OfficeML as a standard interchange format.  Not
entirely, because it won't contain all the necessary info, but it will
contain enough that others will be able to look at your files.   They
probably won't be able to edit it meaningfully, but just being able to look
at it is a big step forward.

>  And the feature would have
> to be supported in some way by the target software (Ooga in your
> example).

not neccessarily all the features, just say 90% or so.  We would do
something reasonable with the other 10%, though there may be some loss of
data.  I'm not looking for a 1:1 feature mapping w/ Word, I'm just looking
for some meaningful interchange.

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

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

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

> For these reasons, while an XML input would be interesting, I don't see how
> an XML output in Office could be really useful except for very specific
> tasks (which could probably be done in a better way by applying an XSLT
> stylesheet directly to the original waggaziggyML document).

ideally, a specific waggyziggy --> Ooga stylesheet would be the best.
However, I know my company does not have the resources to develop a
stylesheet like this with every other company out there.  but we would do it
for OfficeML, as other companies would also, I'm sure.

I definitely agree with the limitations you present of an OfficeML, but I
still think it would be a great thing to have nonetheless.

thanks,
Imran Rashid