forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@wkwyw.net>
Subject Re: Documentv20 --> DocBook
Date Tue, 30 Dec 2003 03:23:42 GMT


Robert Koberg wrote:
> 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?

OK, I'll do my best to communicate what I have interprested from the 
archives, I am sure someone else will chime in if I get this wrong.

XHTML is for the intermediate representation between the users schema 
and the display:


         XSLT           XSLT + CSS
Source -------> XHTML ------------> Display

The idea is that we can X number of source schemas and only one skin.

> 
> If they are preset, why not just make them elements and define them in 
> the schema. As for transforming, this:

This is in the source schema, not the intermediate schema.

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

At the intermediate stage the only reason we need "semantic" info such 
as (in my case) "slide", is because we display it differently. Therefore 
it should be a class.

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

The semantic constraints are in the source schema. The display 
constraints are in the skin. To use your latet example of a faw answer 
after a question. We currently have the FAQ DTD which is converted to 
XDOC and then to PDF, HTML or whatever.

The only thing that will.change is that the FAQ DTD will be convereted 
to XHTML instead of XDoc before converting into whatever other format.

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

But this means that we have X number of intermediate formats. The whole 
point is to use a single intermediate format so that any number of 
source formats can be rendered succesfully with any Forrest Skin.

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

We don't need to validate the intermediate format since it is generated 
from a valid source format.

Ross


Mime
View raw message