forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: XHTML2 I have read it and I like it... GO READ IT!
Date Mon, 12 Aug 2002 07:19:23 GMT
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>> This is the concrete comparisons of the XHTML2 modules we should need 
>> (forms left out for now), please comment on the tags themselves:
> OK...
>>  '-----------------'---------------------------------------'
>>  |  XHTML2 WD2     |       current document11 DTD          |
>>  '-----------------'---------------------------------------'
>>  XHTML  Structure Module
>>     html              document
>>     head              header
>>     title             title
>>     body              body
>>  XHTML Text Module
>>     abbr              * (requested by users via dictionary links)
>>     acronym           * (requested by users via dictionary links)
>>     address           * (requested by users)
>>     blockquote        *
>>     cite              *
>>     br  (deprecated)  br
> If it's deprecated what is the recomended alternative? Is it suitable 
> for our needs?

"line" is the recommended alternative.

>>     code              code
>>     dfn               * (requested by users via dictionary links)
>>     div               footer, legal  (requested by skinners)
>>     em                em
>>     h                 title
> This is not an equivalence. We can only have one title and it is clear 
> where that title should go and how it is used. A heading is a different 
> thing altogether, As Bruno Dumon has already pointed out, this causes 
> problems with numbering (or does it - I confess to not having read the 
> recomendation)

I guess it doesn't. Subsequent headers on the same level get progressive 
numbers. I don't see the problem.

Besides, having an element in a single possible position is usually bad 
seen by users, because they move it inside the body and don't understand 
where it should go.

>>     kbd               * (needed, currently we misuse "code" instead)
>>     line              br
> Is this what is replacing the deprecated br element? If so what other 
> implications does this have?

Yes, it replaces it.
No issues I know of, just

a <br/> b



>>     p                 p
>>     |                 fixme   (with class attribute)
>>     |                 note    (with class attribute)
>>     |                 warning (with class attribute)
> So how do I do this:
> <fixme author="rdg">Stop reading email so late on a Sunday night</fixme>
> I would be tempted to add an optinal author attribute to all elements 
> as, for my purposes this would be useful, but now I am talking about 
> changing the XHTML DTD and I can;t do that. At least with Document V1.1 
> I have a voice if I ever feel the need toargue the case.

>>     pre               source
>>     quote             *
>>     samp              * (needed, currently we misuse "source" instead)
>>     section           section
>>     span              *  (requested by skinners)
>>     strong            strong
>>     var               * (needed, currently we misuse "code" instead)
>>   XHTML Hypertext Module
>>     a                 link (already decided to reduce)
>>     |                 jump (already decided to reduce)
>>     |                 fork (already decided to reduce)
>>     |                 anchor
>>   XHTML List Module
>>     dl                dl
>>     dt                dt
>>     dd                dd
>>     nl                * (basically makes multilinks possible, very cool)
>>     name              * (part of nl spec)
>>     ol                ol
>>     ul                ul
>>     li                li
>>   XHTML Linking Module
>>     link element      book.xml
> How does this affect the libre effort?

It redefines it a bit.

Here each page has its own navigation links potentially, so IMHO we 
could decide that a certain page of a directory has its links always 
present on the left, and the other ones of the pages get added.

We gotta discuss this thing, and could maybe decide to not use them 
(it's a separate module), but anyway they are there if we an them.

>>     Metainformation Module
>>      meta             abstract (never used)
>>      |                authors
>>      |                person
>>      |                subtitle (never used)
>>      |                type     (never used)
>>      |                version
>>      |                notice   (never used)
>>    XHTML Object Module
>>      object           img
>>      |                icon   (never used)
>>      |                figure (never used)
> Most of the items you say are never used are used here. I am not 
> precious about how the info gets in there though, as long as I don't 
> lose any expressiveness. For example, can I still but inline markup in 
> an abstract if it is in the XHTML meta format?

I dunno, but it depends on what you define as an abstract.
Usually it's a brief summary of the book, and IMHO doesn't/shouldn't 
need markup.

Anyway I've never seen it used, so I guess that simple text for it would 
really be enough.

> Can I still indicate that 
> a figure is a figure if I use object (important so that I can label them 
> accordingly and generate a table of figures)?


>>  XHTML Presentation Module
>>      hr               *
>>      sub              sub
>>      sup              sup
> I don't agree this should be in the DTD. This is presentation stuff and 
> should be in the CSS.

hr has a semantical meaning, but we can as well disregerd it in the skins.

As or sup and sub, we already have them, and in some languages they are 
part of the words (content), not presentation.

>>   XHTML Tables Module
>>     caption           caption
>>     table             table
>>     tbody             *
>>     td                td
>>     th                th
>>     thead             * (needed, currently misusing caption)
>>     tfoot             * (needed, currently misusing other tags)
>>     tr                tr
>>> - documentv11 is more device-independent 
>> I disagree. Tell me which above tags are device-dependent.
> Seems fine to me.


> <snip/>
>>> - xhtml2 is not here yet, there's only a very rough first draft, there's
>>> not even a schema or DTD for it.
>> That's not a problem, what we should do is just stay near near the 
>> draft, so that we can conform more easily when it becomes a 
>> recomendation.
> And document v1.1 isn;t stable yet either so we aren't losing anything 
> by adopting this approach - or are we?

I don't think so.
Document DTD started as a semantical-only and simple HTML.
It seems that XHTML2 has the same purpose.

>>>> Please, please, please read it, since I really want to switch 
>>>> Forrest to it.
>>>> It has sections, it removed presentation markup, it's gonna be 
>>>> standard, 
>>> Presentation markup was already deprecated in HTML 4 (= 1998), so that's
>>> not that new.
>> But now it's removed, it's *very* different.
> Still some bits slipped through. I've not read the whole spec but in 
> your list of tags above there is a section that you have titled "XHTML 
> Presentation Module", surely that is presentation!

Three tags, two of which we already have?!?

>>>> what do you want more?
>>> I think it would be best for forrest to become documenttype-independent.
>>> Thus it should be possible to define documenttype-specific pipelines.
>>> (which of course raises the question of how to identify the type of a
>>> document, but that's another matter).
>> Sorry, but I strongly dissent.
>> That's *Cocoon*, not Forrest.
> I agree, and if you really want to you can use Forrest with different 
> DTD's anyway, of course this means a maintenance overhead but that's the 
> choice you take.

Yes, and let me precise a thing.

Forrest DTD has always been a very light semantical markup.
It's more a meta-markup than a very strict one.

The idea is that Forrest can be enhanced with other pipelines and DTDs 
that are then transformed to Document-dtd for reading or skinning.

>>> In the end, the goal of XML is to be able to define application-specific
>>> vocabularies. Different projects or people will always come up with
>>> different requirements. And even in one project, multiple document types
>>> are usefull, e.g. for cocoon it could be usefull to have a document type
>>> for documenting sitemap components.
>>> And it will also become easier to migrate to forrest.
>>> The primary goal for forrest is to be used for the
>>> documentation, so the primary DTD should be one tailord towards
>>> documenting software (but could be html-alike, like it is today).
>> We have documented software for years with this html-like document10 
>> DTD, I don't see why suddenly we need more tags.
>> It's months that Forrest is here, and guess what, no software tags.
>> Besides, Forrest is used for intranets too, so documenting software is 
>> not our goal.
>> That is the goal of Alexandria, which I'm reviving and that will 
>> output to the Forrest DTD, so that Forrest can integrate it with the 
>> site.
>> SOC
>  From the forrest home page "Our first target is to create a consistent 
> website, with a uniform, lightweight and easy to navigate 
> layout and structure. Each project will be responsible for maintaining 
> its own documentation and website", indeed Forrest is for Intranets not 
> *just* documentation.


>>>> It will also give big pubblicity to Forrest, because it will be one 
>>>> of the first implementations of a XHTML2 system!
>>> Programmers shouldn't listen to the marketing guys :-)
>> I'm talking about our users, our community, not marketing guys.
>> Our users have already expressed concern because we don't use DocBook, 
>> but were a bit more happy when they say that document11 looked like html.
>> Since it's *so near* our DTD, why not conform?
>> Think that we will have XHTML2 editors!
>> *This* is a major help for our users.
> Now if these editors are configurable so that they only allow the tags 
> we allow then this is a *big* argument for adopting XHTML2, at least in 
> my mind.

I don't know it the editors will be as configurable as the DTD, and in 
the start maybe they will not be, but if the user just uses these tags 
(which are 98% of what usually is used) it would be no problem.

> So how does this "adopting modules" work? Do we have to adopt every tag 
> in a module, or can we select on an element by element basis?

IIUC we should take all tags, but it doesn't seem like a problem to me, 
seen the above comparison table.

>>>> When Steven comes back from vacation I wanna give a vote on this, 
>>>> because it's really COOL:-D

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message