Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Common Word Processing Format

From: "Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@-----.--->
To: "Uche Ogbuji" <uche.ogbuji@-----------.--->, "bryan rasmussen" <rasmussen.bryan@-----.--->
Date: 12/2/2005 7:14:00 PM
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>
>


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