forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: Documentv20 --> DocBook
Date Tue, 30 Dec 2003 01:21:46 GMT
Hi,

Ross Gardler wrote:

> 
> As a result it can all be captured in the class attribute. How it is 
> presented is then up to the rendering engine, which is exactly what 
> should happen. I have to admit, I was suprised to find that I ended up 
> agreeing with this view, but agree I did once I tried to justify my case 
> with what I thought were rock solid use cases!


I see a few problems if using an (unconstrained) class attribute. First, 
how is the ~schema~ communicated the users? Are they a preset list or 
can they be anything? How do you ensure validity?

If they are preset, why not just make them elements and define them in 
the schema. As for transforming, this:
<xsl:template match="note"/>
<xsl:template match="footnote"/>

seems cleaner than:
<xsl:template match="div">
   <xsl:choose>
     <xsl:when test="@class='note'"/>
     <xsl:when test="@class='footnote'"/>
   </xsl:choose>
</xsl:template>


If the value of the class attribute can be anything then how would you 
keep it consistent (or actually, valid)?

Speaking from a gui dev point of view how would you present the choices 
available to a use? How would you ensure that the user is inserting a 
'valid' element (e.g. there is a policy that the 'byline' comes after 
the title. Or an 'answer' comes after a 'question' for an faq type 
content piece.)?


> 
>> 9) A central document type must therefore be very rich in its
>> description of document structure and meaning - without bias toward
>> media type.

I would suggest that you use XHTML but take out all structural (html, 
head, body, etc) and div/span. Instead of div/span, use what would have 
been the classname. Everything would be defined in the schema so new 
authors can know what they have to work with. There shouldn't be 
structural elements because the content piece might just be one piece in 
a rendering.

> 
> 
> Quite the reverse. It should be as simple as possible, semantic meaning 
> has no place at the presentaional layer, it is only presentation that is 
> important.
> 
> Can you give us a use case in which we need semantic meaning at the 
> intermediate stage in order to do anything *other* than effect how the 
> data is presented.

validation to ensure contracts are upheld from/for a variety of 
different points.

best,
-Rob


Mime
View raw message