Re: Re: DHTML browsers [was Accessibility]

On Mon, 13 Sep 2004 17:29:08 -0500, Ian Bicking wrote
> 
> HTML is a general presentational markup.  If you support HTML, you 
> support the web.  That unlikely to be true with a custom XML markup 

I meant that the CMS and published site should store content as XML, which can
be dynamically rendered (and cached) as HTML for delivery to the browser by
the application server.  Users work with templates that hide the
implementation, never with raw XML, which is stored in a relatively generic
nested item format with attributes and sub-elements.  XHTML can be stored
directly in this tree, or HTML could be XML-escaped.  This should give the
best of both XML and XHTML worlds.  I think some research has been done on
generic XML formats, but don't have the citations and I would probably use
Dublin Core or whatever for metadata (a completely separate thread, what is
the difference between content and metadata?).  The published site should only
send XML to the browser when it identifies a version that can reliably perform
XSL translation on the client.  Otherwise the appserver needs to perform the
XSL transformation and send HTML to the browser.  I did this with a few
hundred lines of C# implemented as a .NET HttpFilter last year.  It took less
than a day and the content was inherently reusable when the portal was built;
I'm not sure how much work it would be in Java, PHP, etc.  Add to my list of
issues with this solution the potential that it may be overkill for a small
sites without much dynamic content.    

> A good example would be an ecommerce 
> site -- it's not reasonable to express product availability or price 
> in a free-form manner.  

I have always argued that the CMS is not the right place to build product
master in the first place, but lately I have seen a CMS that could be used to
build front-ends to any enterprise resource, which may change my perspective.
 Comments?

> In many 
> cases, I think we err too much on the side of structure.  

Other than poor attempts to help users create tables, I have never seen this.

> E.g., does 
> the product image have to be part of the structure?  I think it 
> would usually be better to leave the entire description as a single 
> hunk of free-form HTML, and create better tools so that you could 
> simultaneously maintain a thumbnail display, detailed specs, etc.

Maybe I am misunderstanding, but I don't see how you would do this without
structuring the data into fields.  I think consistency in presentation is
crucial for product detail pages.