[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Common Word Processing Format

• To: "Uche Ogbuji" <uche.ogbuji@f...>, "bryan rasmussen" <rasmussen.bryan@g...>
• Subject: RE: Common Word Processing Format
• From: "Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@c...>
• Date: Fri, 2 Dec 2005 11:14:04 -0800
• Cc: "Robert Koberg" <rob@k...>, "Peter Hunsberger" <peter.hunsberger@g...>, "Bullard, Claude L \(Len\)" <len.bullard@i...>, <xml-dev@l...>
• Thread-index: AcX3VcQATfRllbG9RvWWDzGNj3MenwAGnawg
• Thread-topic: Common Word Processing Format

Hi.
 
> My point was: use the best format for the task, and don't be afraid to
> invent a new format if it's others are fitting a square peg 
> into a round
> hole, but never, no never play the 
> tunneling-markup-in-protean GI game
> of
> 
> <div class="monty">
>  <span class="python"/>
> </div>

From a core of basic agreement I have a couple of objections.

The first, which I think is echoing things Robert has also said, is that
if part of the task in "use the best format for the task" is sending out
documents to be edited by XML illiterate users, then making up my own
markup language is just not an option.  The lack of good authoring tools
has killed structured authoring for end users in the organization I work
for.  Far more people use MS Word with webworks templates than use
XML.... and not only for historical reasons, the uptake is actually
faster.  I have my fingers crossed that in the next couple of years this
will change.

The second is that there are times where the kind of
schema-tunneling-through-attributes is a good design pattern.  Layering
semantics on XHTML using attributes is a big step up in expressiveness,
and a necessary design pattern if you want to use CSS for formatting
complex pages.  To me this is a perfectly valid use case:

<ul class="navigation">
 <li><a href="home" class="home-link">home</a></li>
 <li><a href="next">next</a></li>
 <li><a href="previous">previous</a></li>
</ul>

Many microformats are also valid design patterns to my eye.  XFN is a
case in point, where a lightweight layer of naming conventions for the
values placed in rel attributes of links allows blogrolls to be
traversed and parsed as a rudimentary social network:

http://www.gmpg.org/xfn/

It's a case of taking content that's already quite common on web pages
and using markup conventions to add value for the machines.

The boom microformat (in my opinion) crosses the line into "tunelling
markup considered harmful"

We're no longer talking about using XHTML for the browser, but for
print, and creating a microformat that substantially re-purposes XHTML:

http://www.alistapart.com/articles/boom

Here's a specific example from boom that kind of bothers me, where XHTML
is used to markup a standard print element which document formats like
docbook have built in explicitly:

<div class="table">
  <p class="caption">...</p>
  <table class="lined">
    ...
  </table>
</div> 


---------->N

> 
> *OR*
> 
> <text:p text:style-name="monty">
> <text:span text:style-name="python"/>
> </text:p>
> 
> Unless that's really sensibly an XHTML class or an OOXML style.
> 
> 
> -- 
> 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>
> 

• Follow-Ups:
  • RE: Common Word Processing Format
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: Preserving whitespace between nodes - XSLT
• Next by Date: Re: Common Word Processing Format
• Previous by thread: RE: Common Word Processing Format
• Next by thread: RE: Common Word Processing Format
• Index(es):
  • Date
  • Thread