Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Common Word Processing Format

From: "Bullard, Claude L (Len)" <len.bullard@----------.--->
To: xml-dev@-----.---.---
Date: 12/2/2005 7:37:00 PM
So this point boils down to denying XHTML is 
a word processing format. Some disagree.  

Further, they make their case with published 
examples. Uglyness in markup is in the eye of 
the beholder.  Formatted results speak for 
themselves.

I think Uche may be going a bit further and 
saying that a common core for word processing 
isn't valuable in his shop.  I take his word 
for that if that is what he intends.  The 
Commonwealth of Massachusetts and other states 
and nations following their lead assert that 
at scale, costs and sovereignty rights (open 
access, open markets as determined by sovereign 
states) this is not true for their procurement. 

So the issue is squarely back to what could be 
in such a common core or if it is better to 
simply select one of the available options.
So far:

o  For some, XHTML + CSS + n are sufficient, are 
standard, and are cost efffective.  This is a 
viable option.

o  For some, XHTML + CSS + n don't do enough or 
don't have sufficient support to make the task 
cost effective for some jobs.  This is possibly 
so but the case has not been made.

o  The choice of OpenDoc vs MS OfficeXML comes 
down to procurement policy goals and costs for 
the Commonwealth.  Others following this story 
will want to separate the politics of procurement 
provenance (aka, who gets to call the shots) from 
the issue of right tool for right job.  They will 
want to follow this debate and the results.

Given a market of server-side components, high level 
building tools, and just in time delivery with the 
web as the dominant distribution medium, it is too 
early to pick the winner even if one winner is possible. 
Note that this is a separate issue from goal-directed 
policies for procurement.

It is evident that the market for the highly complex 
and costly word processing tools is shrinking.  It is 
probably in the best interests of all of the vendors 
providing core components in a loss leader sales situation 
to pursue a common core for mutual self-interest.

Otherwise, Google just wipes up the floor with you.

len


From: Uche Ogbuji [mailto:uche.ogbuji@f...]

XHTML's GIs are designed for expressing Web documents.  Office format
GIs are designed for expressing office documents.  My point is that I do
not want to tunnel one within the other.

> Why text:p is better than xhtml:p I just don't get.

I never said one is better than the other.  xhtml:p is fine for XHTML.
text:p is fine for ODF.  What's not to get?


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent