Fwd: [xml-dev] Common Word Processing Format

[Kurt Cagle <kurt.cagle@gmail.com>]

Whoops.

---------- Forwarded message ----------
From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Dec 2, 2005 1:12 PM
Subject: Re: [xml-dev] Common Word Processing Format
To: Uche Ogbuji <uche.ogbuji@fourthought.com>

There's an intriguing point buried here - if I was an HR director (or the IT person responsible for working with the HR director) - I'd much prefer a specialized format for a CV that contained the requisite semantics for describing that person in terms of job skills, work history, salary requirements and so forth. I would prefer NOT to have to parse an HTML file that contained this information, even if it used GIs to do so if I could rely upon the structure being consistent. However, chances are good to near certain that getting anybody but XML geeks to write their CVs in such a form is pretty much a lost cause, especially if everyone DOES in fact roll their own CV format.

Can you define a word processing converter that will make development of that CV possible? Sure.The question ultimately comes back to how useful is the effort of putting the resume together for different potential interface systems worth to that user. To me, the ideal tool would be one that would let me use WYSIWYG type functionality combined with structural "hints" that would let me create the document without being aware of the underlying XML, that I could then combine with a web services type interface to identify the desired format to be consumed and a set of transformations for mapping the document to the appropriate format.

Consequently, it seems to me that we can get too much wrapped up in whether this or that format is the "best" when it is better to see any of these formats as being simply intermediate stages, application specific languages that are better than proprietary ones because they can be pipelined, but not necessarily the best vehicle for storing domain specific knowledge.

-- Kurt

On 12/2/05, Uche Ogbuji < uche.ogbuji@fourthought.com> wrote:

On Fri, 2005-12-02 at 10:08 -0800, Michael Champion wrote:
> >Of an office format is too complex for your need, then of course I
> >wouldn't advocate it.  My point is that reducing all use cases to XHTML
> >is just as bad.
>
>
> At least as I understand Len's point (from the XML 2005 townhall) the
> problem is that real people have a need for real document format standards
> that are really supported and  really open TODAY.  What MS will do in Office
> 12 (or what can be done in Office 11 with some user training) , and what
> could be done in ODF once the little detail of deployment and conversion and
> training is out of the way, is not very helpful to people with the problem
> now.  (X)HTML is good enough for a *lot* of these use cases, is univerally
> supported, and both a de facto and formal standard.  So what's wrong with
> it?

Umm, don't you have the same deployment and conversion issue with XHTML?


> 1) It's easy for easy things but very hard for hard things.
> 2) It is a classic "worse is better" solution which makes geeks gag.

Since when did geeks gag at worse-is-better?  Geeks *invented*
worse-is-better.

I'm sorry, but you're being *way* too general here.  Using XHTML to
represent a CV is worse-is-better, and it makes sense to me.  Using
XHTML to for the entire class of office documents could also be
considered worse-is-better but it sure as hell does not make sense to
me.

There are shades of worse-is-better, so the expression is not much use
in this conversation.

> 3) It doesn't strike a blow against the Empire.

Huh?  What empire?  What are you on about?


> OK, but:
>
> 1) Most of the stuff that really has to be authored and read by anyone,
> anytime fits within HTML, as shown by its dominance on the Web.

And have you checked with real users whether they prefer Office apps or
Web authoring apps?

> 2) Call it "disruptive innovation" and the suits will be happy, and they
> make the decisions.

No comment on buzzword bingo.

> 3) The Empire is going to support whatever it has to support to make a buck,
> don't kid yourself.  ODF might scratch the black armor a bit, not cut off
> Darth's breathing apparatus, even *if* it proliferates rapidly.

Are you talking to me?  In my post I posited that *Microsoft* Office XML
alongside ODF as a better approach for office docs than XHTML.

> I (and my little core of the Empire) would be very happy if this scenario
> doen't play out, but custom schemas and even free-form XML markup
> proliferate.  Diversity and customization of markup just creates more demand
> for the stuff that most of us build or explain. But I'm not going to hold my
> breath.

Umm.  If you haven't noticed.  Creating custom XML vocabularies is the
*norm* in IT, not the exception.  I wouldn't hold my breath that
everyone is going to ditch MyDepartmentML in favor of XHTML everywhere,
and I'm glad for that.


--
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                     http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org < http://www.xml.org>, an
initiative of OASIS < http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>

-- 
Kurt Cagle
http://www.understandingxml.com


-- 
Kurt Cagle
http://www.understandingxml.com