[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forrest-dev
Subject:    Re: Project sitemap mount and copyless
From:       Nicola Ken Barozzi <nicolaken () apache ! org>
Date:       2004-06-29 18:09:23
Message-ID: cbsb9u$81m$1 () sea ! gmane ! org
[Download RAW message or body]

Lorenz Froihofer wrote:

> Nicola Ken Barozzi wrote:
> 
>> Coloring should be done in skins. For this we are adding a class 
>> attribute on all elements, so you can color things in skinconf (with a 
>> new extra-css section).
> 
> I guess you mean that this class attribute is added during pipeline 
> processing and not to the xdoc DTD. 

No, I mean in the xdoc DTD.

> If it were added to the xdoc DTD 
> this would allow to distinguish for example between different types of 
> paragraphs (<p>). This feature would be very useful but also provides a 
> way for missuse, e.g. if the class attribute is used to define classes 
> like class="bold" or class="red".

It could, but we cannot totally prevent things from being used badly.
Used wisely it's a much better way of customizing stuff without having 
to make a new DTD.

>>>> What about this proposal:
>>>>
>>>> - we mount a sitemap that resolves uris in a defined space, for
>>>>   example /forrest-user-sitemap
>>>> - this pipeline has to give us the docs in xdoc format
> 
> The issue with this approach is that you limit every possible content to 
> the capabilities of the xdoc format ==> the xdoc format is the lowest 
> common denominator. What happens if you cannot transform the custom 
> content into the xdoc format?

Then Forrest is not adeguate for the job ;->

> ...
>> The xdoc format does not contain any style information per design, so 
>> I don't understand what you mean by 'more flexibility in formatting'.
>>
>> Could you please post an example?
> 
> I know that the xdoc format does not contain any style information and 
> this is well thought.
> 
> What came to my mind was that sometimes you might have a lot of existing 
> html documents, possibly with custom *.css definitions that you want to 
> integrate into a Forrest site. These html files may further make use of 
> the class attribute to allow the definition of styles based on the 
> content of the class attribute.
> 
> There are some cases, where you want to ensure that the layout of at 
> least some of the existing html files is preserved while you still want 
> the menu and the tabs of the Forrest site to be visible for these files.
> 
> Examples:
> *) Inappropriate layout of a page destroys its readability
> *) A page should keep it's layout regardless of the used skin
> *) A page displays content that needs special formatting but the type of 
>  content is not used often enough to be worth the overhead of defining a 
> DTD and custom stylesheets.
> 
> As currently all attributes are stripped from HTML input, one can use 
> the approach to define a new pipeline (in sitemap.xmap). The 
> transformations in this pipeline ensure that the class attribute (and 
> possibly other attributes) of the html elements are preserved.
> 
> I know that this does not adhere to the approach of separation of 
> concerns but allows easier and faster migration to Forrest.
> 
> My suggestion would be to have two different file endings for html 
> files, e.g. .xhtml and .pxhtml. For one type of html input (e.g. the 
> .xhtml files or the already existing .ihtml files) the attributes are 
> stripped from the html elements and the input is integrated into the 
> generated output the way as it is already done. For the other type of 
> input (e.g. .pxhtml => preserved xhtml), the attributes of the html 
> elements are preserved during pipeline processing to allow a mix between 
> content and style in these files.
> 
> One problem with this approach is that possible style information in the 
> .pxhtml files from above is limited to html output. What happens, if the 
> .pxhtml file should be rendered to pdf? May be limit such files with 
> mixed content + style to html output?

I have kept all this in the reply because it's well written and 
summarizes very well a discussion we have had on this list many months 
ago :-)

Html processing has always been seen in two ways. One way is that all 
that can not be converted in xdoc should not pass, for good separation 
and so that it can be outputted in all formats. Instead, some need all 
to pass, like you describe above.

Since we could not agree what the html extension should do, we created 
two extensions:

  *.ihtml - it strips all unrecognized tags
  *.ehtml - everything passes through

It has been like this since some time, although not many know about it, 
even if it's in the forrest-seed.

In any case, we have now changed direction since then and have decided 
to make html basically work like ihtml, as our mission is now clearly 
separation of concerns.

But to ease things we have decided that:
  1 - we will use xhtml as a format; this will make all xhtml tags
      available, and thus not limit at all in the main html output
  2 - we will have Forrest pass tags that we do not recognize but that
      are in this schema

Currently we are just before the switch,that should occur in the next 
versions :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]