[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Common Word Processing Format
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/ >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|