[
Lists Home |
Date Index |
Thread Index
]
- From: Joshua Allen <joshuaa@microsoft.com>
- To: 'Michael Champion' <Mike.Champion@softwareag-usa.com>, xml-dev@lists.xml.org
- Date: Tue, 25 Jul 2000 22:04:41 -0700
After some excellent suggestions from Julian got me
thinking, I did some more research and found this
fairly obscure link:
http://msdn.microsoft.com/library/officedev/ofxml2k/ofhtml9.exe
It has pretty complete documentation about all of
the office 2000 XML document formats, including
DTDs for the various formats. Basically, Office 2000
uses XHTML to save documents, and then uses CSS to
format. The XHTML *is* well-formed, so you can create
office docs on any platform that uses XML. In fact,
I found a neat page at
http://www.dominopower.com/issues/issue200002/xml2001.html
that tells how to use lotus script on a domino server
to emit Office 2000 documents dynamically over the web!
Funny it took a Lotus Notes guy to explain to me what
kind of XML stuff can be done with Office...
Now, there are some potential criticisms of the O2k approach:
1) It emits and imports XHTML instead of XML. Actually, this might not be
so bad, since (X)HTML was meant to specify document formatting anyway,
right? Anyway, this should improve.
2) Considering when it was released, it uses DTDs heavily and uses some XDR
in there, too. It will probably shift more toward XSD in the next release.
3) Lots of CSS instead of XSL. The CSS is designed to degrade gracefully to
various browsers, and formatting semantics are still tagged in the XHTML;
CSS simply defines the implementation of the formatting. There's no reason
you couldn't run XSLT against the office 2000 XHTML, though, as long as the
final output is still XHTML with the valid tags, it should load in office
fine.
For non-document data like settings, etc. there are various
places where O2k uses straight XML as well, documented in that
help file above. Finally, one thing I found fairly cool: take
any web server, JSP, Servlets, ASP or whatever. Write a page
that sets content-type header to "application/x-msexcel". Now
output your data as an XHTML table. As long as the user
has Office 2000 on their machine, when they browse to your
page, it will load the data as an excel spreadsheet directly in
the browser. I imagine the same goes for word and other apps;
so it should be fairly trivial to dynamically generate office
docs from non-MS systems.
Also someone mentioned that you can use an editing tool
like Frontier, then take the XML generated thus, use something
like Ishtar (I think?) to convert the XML to RTF and import
into older versions of Word, like Word 6.0 or whatever..
I probably have just barely scratched the surface on dumb
tricks you can do with XML and Office; please forgive my
posting potentially off-topic stuff; I just know this seemed
a big question recently, particularly with regards to office...
Thanks,
Joshua
> -----Original Message-----
> From: Michael Champion [mailto:Mike.Champion@softwareag-usa.com]
> Sent: Monday, July 24, 2000 1:57 PM
> To: xml-dev@lists.xml.org
> Subject: XML in .NET - more than just SOAP?
>
>
> I didn't get a reply to a previous query, which was buried
> deep in another
> message, about the role of XML in Microsoft's .NET
> initiative. I'm not
> ranting, trying to flame .NET, or questioning C# ... just
> trying to figure
> out the answer to one question:
>
> A typical article on .NET in the trade press says something like
> "Microsoft is basing everything on the Extensible Markup
> Language" (in this
> case, I'm quoting from
> http://www.iweek.com/author/redmond.htm) I've read
> the .NET whitepaper, various PDC presentations, and much
> punditry about .NET
> and the only XML-related components of .NET I hear about are
> related to
> SOAP. Is that all that XML has to contribute to the publicly
> stated vision
> of .NET, or am I missing something?
>
> More specifically, is there anything about publishing XML
> formats for the
> actual content of Office documents (including spreadsheets,
> PPT slides,
> etc.)? What about WebForms; is that an XML technology? Can 3rd parties
> interoperate with .NET components in any way other than via the
> "intermediate language" and its virtual machine? One could imagine
> interoperating with .NET services by exchanging XML
> "document" data rather
> than RPC calls with representations of proprietary objects
> encoded in SOAP,
> but I'm not finding any direct references to this.
>
> Thanks for any help answering this.
>
|