RE: [xml-dev] Common Word Processing Format

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

Hi.

> 
> http://www.xml.com/pub/a/2005/02/09/xforms.html
> 
> I asked Chimezie on IRC and his answer was FormsPlayer.

Thanks, I will look at XForms implementations again.  It's been 6
months.

> > The point here is that plain XHTML isn't enough to do a 
> nice job with
> > web delivery.  I need to layer some semantic and/or formatting
> > information on top in order to satisfy my requirements (and this is
> > common in front end code design).
> 
> That's a strange place to have an "or", I think.  If you need 
> a semantic
> layer, surely it can't be replaced by a formatting later, and vice
> versa?

The preferred scenario is that CSS is my formatting layer and the markup
I add to XHTML provides hooks for the CSS but is semantic in nature.
The nav example I gave before being an example of this.  Otherwise there
may be times when I don't get to know what something means and am told
"make it look this way".  In that case the markup I add to the XHTML
doesn't have much semantic ooomph and is more about the way something
looks:

<div class="spotlight">
  <h3>how to be great on a budget</h3>
  <p>Lots of glowing verbiage here</p>
</div>

Where "spotlight" is marketing jargon for "thing that stands out
visually in a way that marketing redefines every three months"

That's where the "or" comes from.  Structurally it may not be that big
of a difference weather the class attribute holds meaning ("this is
about navigation") or just formatting hooks ("this is a thing to refer
to in CSS selectors")  but it makes a difference to me when I think of
it.

> I think that Microformats are a sleight of 
> hand trick to pretend to be solving a semantic problem, when they
really 
> just re-solve the same syntactic problem that XML already has done.
All 
> Microformats did was emphasize anew the fact that what we really need
is a 
> revival of Architectural Forms (as discussed elsewhere in this
thread).

For architectural reasons that are too complex to go into here, it
sometimes makes sense for us to re-build our taxonomy by crawling and
parsing existing web pages.  The half-baked semantics we did layer onto
our XHTML navigation paid off in a big way when that problem got thrown
at us, and our next generation front end code for navigation (and in
fact the whole page) has been informed by the exercise.

Given the benefit we've gotten from enriching the semantics of our pages
using class and ID attributes, and given that we're not going to be
moving from XHTML to a purpose built semantic representation of our web
pages any time soon, it looks like we're going to be tunneling for a
while yet, and much happier for it.

I'm in total agreement that in the abstract it's an ugly way to design
things.  I'd like to understand better how Architectural Forms would
address this.

On the flip side I'd certainly want to avoid using XHTML + semantics
tunneled through attributes for anything that wasn't already and always
to be a web page... hence my objection to boom, and to XHTML used as a
WP format.


---->N




> 
> 
> -- 
> 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/
>