Re: Re: DHTML browsers [was Accessibility]

cms-list wrote:
> 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.  

That's what I was thinking too.  But rendering to HTML implies that you 
are using a separate markup, and there's probably not a one-to-one 
connection between HTML and your XML markup.

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

You could do that in other systems, though (for instance) XSL isn't very 
popular in the PHP world.

The overhead that I'm concerned with is when there's a desire for a new 
kind of content -- if that requires feedback with a developer, I think 
that puts up a big barrier, and makes it hard to deploy the content in a 
timely manner.

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

Strange, I see it constantly.  With too much structure, it can be hard 
to encorporate unusual requirements.  For instance, you might not 
initially think you need markup in your title, but at some point someone 
wants to use a title like "Review: <i>A Book Title</i>".  Or, you lay 
the image out automatically, but in some case the layout doesn't look 
right.  Maybe someone wants the image to float on the opposite side of 
the page.  Or you didn't allow for expanded views of images, but one 
particular image has detail that justifies it.  Or you have an author 
field that deal well with a case where there's a hierarchy of authors, 
grouped by organization.  In all cases you *could* incorporate this into 
the XML and into the rendering, but it's not realistic to think we know 
all future requirements/requests for content.

To the degree that content is eclectic, I find that structure can cause 
problems.  It can keep the content from being as expressive as it might be.

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

I don't think that's necessarily true.  We're talking about content for 
human consumption.  For instance, consider a product that has several 
variations.  In that case, you might want to present the product as 
being "Like product X, but with feature Y and Z".  You can program that 
into the site and the data display, but that's a lot of work, and 
there's a good chance you'll never be able to automatically create that 
delta detail sheet very well.  There's always something people don't 
forsee -- and often when trying to forsee all possibilities, people come 
up with all sorts of things that are never needed or used.

In part it's a matter of trust -- if your authors can be trusted to 
create good content, then it's better to get out of their way.  Of 
course, not all authors create good content, because they may not be 
experienced enough with the standards, they may not know the material 
terribly well, they may not be very thoughtful.  I like to assume the 
users I'm working with are intelligent and competent, but then I usually 
lose out when arguing decisions based on that.  Users usually aren't 
decision makers, and there's little trust in the workplace.  Oh well.

-- 
Ian Bicking  /  [email protected]  /  http://blog.ianbicking.org