You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/09 23:44:49 UTC
XHTML2 I have read it and I like it... GO READ IT!
XHTML2 working draft
http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
Look at this XHTML2 snippet, and see if it looks familiar:
<body>
<h>This is a top level heading</h>
<p>....</p>
<section>
<p>....</p>
<h>This is a second-level heading</h>
<p>....</p>
<h>This is another second-level heading</h>
<p>....</p>
</section>
<section>
<p>....</p>
<h>This is another second-level heading</h>
<p>....</p>
<section>
<h>This is a third-level heading</h>
<p>....</p>
</section>
</section>
There is also a del and an ins elements that can denote parts of the
document that are deprecated or drafts
http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-edit.html
Then the meta module
(http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-meta.html) for:
<head profile="http://www.acme.com/profiles/core">
<title>How to complete Memorandum cover sheets</title>
<meta name="author" content="John Doe"/>
<meta name="copyright" content="© 1997 Acme Corp."/>
<meta name="keywords" content="corporate,guidelines,cataloging"/>
<meta name="date" content="1994-11-06T08:49:37+00:00"/>
</head>
It will also have a schema, and has just one module for presentation
# 17. XHTML Presentation Module
* 17.1. The hr element
* 17.2. The sub element
* 17.3. The sup element
With hr element deprecated.
Now, I really like this. It's bascally a standard version of our
document DTD.
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,
what do you want more?
It will also give big pubblicity to Forrest, because it will be one of
the first implementations of a XHTML2 system!
When Steven comes back from vacation I wanna give a vote on this,
because it's really COOL:-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Ivelin Ivanov <iv...@apache.org>.
Since I was one of the people who asked for DocBook,
I would chime in that a presentation independent subset of standard XHTML 2
is preferred to a proprietary language.
Regards,
Ivelin
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
To: <fo...@xml.apache.org>
Sent: Sunday, August 11, 2002 3:52 PM
Subject: Re: XHTML2 I have read it and I like it... GO READ IT!
> Bruno Dumon wrote:
> > On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
> >
> >>XHTML2 working draft
> >>http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
> >>
> >>
> >>Look at this XHTML2 snippet, and see if it looks familiar:
> >>
> >><body>
> >><h>This is a top level heading</h>
> >><p>....</p>
> >><section>
> >> <p>....</p>
> >> <h>This is a second-level heading</h>
> >> <p>....</p>
> >> <h>This is another second-level heading</h>
> >> <p>....</p>
> >></section>
> >><section>
> >> <p>....</p>
> >> <h>This is another second-level heading</h>
> >> <p>....</p>
> >> <section>
> >> <h>This is a third-level heading</h>
> >> <p>....</p>
> >> </section>
> >></section>
> >>
> >
> > Doesn't look entirely familiar to me. I see a section which can have two
> > titles, and the first title is not in the beginning of the section.
> > Strange. Usually, in the rendered version of a document, the title is
> > the only means to identify that a new section starts. And if there are
> > two titles for one section, how will they be numbered?
>
> It's a heading, not a title. It has a slightly different meaning.
> But I concede that there is a difference, though I don't really know if
> it's an issue or feature.
>
> >>There is also a del and an ins elements that can denote parts of the
> >>document that are deprecated or drafts
> >>http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-edit.html
> >>
> >>
> >>
> >>Then the meta module
> >>(http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-meta.html) for:
> >>
> >> <head profile="http://www.acme.com/profiles/core">
> >> <title>How to complete Memorandum cover sheets</title>
> >> <meta name="author" content="John Doe"/>
> >> <meta name="copyright" content="© 1997 Acme Corp."/>
> >> <meta name="keywords" content="corporate,guidelines,cataloging"/>
> >> <meta name="date" content="1994-11-06T08:49:37+00:00"/>
> >> </head>
> >>
> >>It will also have a schema, and has just one module for presentation
> >># 17. XHTML Presentation Module
> >>
> >> * 17.1. The hr element
> >> * 17.2. The sub element
> >> * 17.3. The sup element
> >>
> >>With hr element deprecated.
> >>
> >>Now, I really like this. It's bascally a standard version of our
> >>document DTD.
> >
> >
> > I have the impression that there are a lot of differences:
> >
> > - documentv11 is still a *lot* simpler than xhtml2, meaning that it is:
> > - simpler to learn
> > - less work to write stylesheets
> > - more restrictive, thus less ways to do dirty hacks
>
> It's not true. I never talked about implementing the *whole* spec.
> Also, since html is *extremely* more known, XHTML2 is simpler to learn.
> Think about link versus a... besides, in some ways documentDTD is
> already more difficult than xhtml (links).
>
> This is the concrete comparisons of the XHTML2 modules we should need
> (forms left out for now), please comment on the tags themselves:
>
>
> '-----------------'---------------------------------------'
> | 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
> code code
> dfn * (requested by users via dictionary links)
> div footer, legal (requested by skinners)
> em em
> h title
> kbd * (needed, currently we misuse "code" instead)
> line br
> p p
> | fixme (with class attribute)
> | note (with class attribute)
> | warning (with class attribute)
> 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
>
> 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)
>
> XHTML Presentation Module
>
> hr *
> sub sub
> sup sup
>
> 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.
>
> >(think of html tags for
> > scripts, objects, forms, css, image maps, ...).
>
> We don't have to use all modules, and in fact we wouldn't.
>
> - Scripts we keep out.
> - Css is in the skin.
> - image-maps, we should support them in the future, but they can keep
> out for now
> - objects, it's images and SVG, which we *do* support
> - forms is something we miss that we need. Look at the simple fact that
> we needed them for a mail form and couldn't do it OOTB.
>
> > - documentv11 is in our hands, so it can be tailored towards our needs.
>
> XHTML is extensible, with span and div tags, but usually a class
> attribute suffices.
> Anyway, we can add our tags if it's *so* important, but ATM it's really
> not needed.
>
> > - 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.
>
> >>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.
>
> >>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.
>
> > 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 xml.apache.org
> > 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
>
> >>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.
>
> >>When Steven comes back from vacation I wanna give a vote on this,
> >>because it's really COOL:-D
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Steven Noels <st...@outerthought.org>.
Marc Portier wrote:
> Steven is a big guy, he can handle loads of catch-up reading :-)
> If momentum is (t)here, his absence should not keep us from discussing and
> investigating. (don't think he'ld like us to be paralized)
+1
> (oh man, I can't wait to have him around again: moaning on several 1000 msgs
> in his box killing his rules etc etc :-))
3982 to be exactly, and no rules-processing errors whatsoever since I
use a decent MUA -)
I'm baaaack! ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
RE: XHTML2 I have read it and I like it... GO READ IT!
Posted by Marc Portier <mp...@outerthought.org>.
some snap thoughts...
[disclaimer] I'm no docuhead, so I really don't see myself as the DTD and
document organizing expert, yet this comes to mind:
- having the pragmatic view on these DTD things I see a big resemblance to
our current one, so the naieve question 'why not reconsider?' comes quite
spontanous
- from the libre/book.xml point of view I like that <nl> :-) (can i be
excused?)
- since we want to have other tools generate content to be included in the
site (javadoc, syntax-highlight...) support for a more standard schema makes
sense (e.g. redoing the alexandria jxr to spit out what we want)
- indeed people with more skills in this area (that have the brain, nerve
and patience to read the full spec on xhtml, which is very unlike me) should
have their say, I'll be happy to learn from this discussion
> > When it does come time for this, is it better to experiment
> > in Forrest's scratchpad, rather than manage branches?
> > We already have some scratchpad build targets for doing
> > transformation and processing of other document types.
>
> But this is about converting all the documentation in XHTML, should I
> copy all of it in scratchapd?
>
mmm, I'm not particulary fond of the branches idea either
1. purely community-wise I'ld like us to come to aggreement before massively
proceeding in all directions, smaller tests and try-outs can be done
off-line and presented to each other, no? (I see how David comes to
proposing scratchpad for those that would have the feeling that these tests
need to be in cvs. In the same line of thought: if that person would need
ALL documents to be converted to proove a point... :-)) There is time
enough to convert ALL documentation after we've agreed on doing so.
2. purely feature-wise we should have a system inside forrest that allows us
more easily to handle new upcoming DTDs like this. It would also allow our
users to take advantage.
So this brings me back to:
as I said in another thread: the dream of the content-aware pipeline isn't
realized yet, so we need to think about how forrest can elegantly learn
about new src-content types (some of them auto-generated by other
tools/cents) and thus new pipelines to publish them.
(I'm more and more thinking of reusing layout.xml and content-type
describing files to be merged into a xslt?-process-generated sitemap... that
in combination to **.dtdx.html like URL-suffixes to get the pipelines going)
> OH well, let's wait for Steven to come back even only to discuss, or the
> sky will fall...
>
Steven is a big guy, he can handle loads of catch-up reading :-)
If momentum is (t)here, his absence should not keep us from discussing and
investigating. (don't think he'ld like us to be paralized)
(oh man, I can't wait to have him around again: moaning on several 1000 msgs
in his box killing his rules etc etc :-))
-marc=
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>David Crossley wrote:
>>
>>>Nicola Ken Barozzi wrote:
>>>
>>>
>>>>An interesting article on XHTML2, for those who don't
>>>>want to read the spec :-P
>>>>
>>>>http://www.xml.com/pub/a/2002/08/07/deviant.html
>>>>
>>>>Since there has been quite a good reception on switching the documentDTD
>>>>over to a profile of XHTML2wd, I think that maybe the best thing could
>>>>be to make a branch, change there the DTD, check that it all works, and
>>>>ask a vote for a branch switch.
>>>>
>>>>What do you think?
>>>
>>>I think that you are reading a lot into a short discussion.
>>
>>We have already discussed a *lot* about using XHTML modules in Forrest,
>>and I understood that it was agreed to try them.
>>Also, we had decided to merge all links into one, make the class
>>attribute available, and look at the libre effort.
>
> Ken, if you have the energy to explore it at this stage,
> then please do.
Ok.
>>>We should wait until there are some DTDs available. We need
>>>the next Working Draft.
>>
>>Why?
>>We already have our DTD, we just need to change *some* tags to conform
>>for now, so that the changes we have *already* decided to make are done
>>in conformance to the draft.
>>Since we *have* to do them soo, IMNSHO it's better to do them according
>>to the spec, which is surely more near to what it will be like than our
>>current DTD.
>
> It looks to me like it is not only simple mapping
> of tag names. Rather there are some structural changes
> that are not yet fully decided nor described via schema/DTD.
I have taken time to show you what the differences are and how we could map.
Please tell me what exactly, this doesn't make the discussion advance.
>>>Also i browsed their recent discussion
>>>archives and this makes me feel that it is too early.
>>
>>Too early to make our DTD *similar*?
>>Too early for what?
>
>
> See Masayasu Ishikawa comment on the status:
> http://lists.w3.org/Archives/Public/www-html/2002Aug/0119.html
>
> They are still discussing major issues ...
>
> * XLink and hlink ... you see the following subject
> on current www-html, www-tag, xml-dev lists:
> XHTML 2.0 and the death of XLink and XPointer?
> http://lists.xml.org/archives/xml-dev/200208/msg00827.html
I read them.
IMHO they are going to keep the <a> tag.
Since we have a link tag, we should just do
link (fork, ...) -> a
> * href attribute on many different elements.
We don't need to implement that now.
> * Block elements within block elements
> e.g. <p> can now contain <ul> and other block elements
There is no need to implement that now.
> All these things have big impact on our XSLT. And how
> can we be "switching the documentDTD over to a profile
> of XHTML2wd" when they do not yet have a DTD?
Ok, let me repeat it.
">>Too early to make our DTD *similar*?"
Since we have to make some DTD changes, I assume that using same element
names of XHTML2 where they apply would be better.
No "profile" to be used now of course.
>>>We need to allow time for more discussion on whether this is
>>>the way to go. Some prime Forrest people are away.
>>
>>As I said from the start, there will be no vote till all of the Forrest
>>developers can have their say, and after a good discussion.
>>
>>And I haven't yet heard from you.
>
> Maybe you will, maybe not ... no time for everything.
Then you don't have time to veto ;-P
>>>When it does come time for this, is it better to experiment
>>>in Forrest's scratchpad, rather than manage branches?
>>>We already have some scratchpad build targets for doing
>>>transformation and processing of other document types.
>>
>>But this is about converting all the documentation in XHTML,
>>should I copy all of it in scratchapd?
>
>
> That is what the scratchpad targets are doing - automated
> conversion to a different document type. They will help you
> to transform some current xdocs to the XHTML2wd.
>
> If you think that the result of this conversion is best
> explored in a new branch, then go for it.
>
> Sure, the best way to explore something is to try to implement
> it. Excellent if Forrest can provide them some feedback on any
> implementation problems before they become concrete. I have
> battles in my geospatial community because they develop
> standards without trying to implement them.
Ok, I now think that a scratchpad example is the best, will go for that.
>>OH well, let's wait for Steven to come back even only to discuss, or the
>>sky will fall...
>
> Steady on Ken, no need for sarcasm.
Come on, it was a citation from Peter Donald ;-)
I keep reading it so often on the Avalon list that I couldn't resist
using it myself ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> David Crossley wrote:
> > Nicola Ken Barozzi wrote:
> >
> >>An interesting article on XHTML2, for those who don't
> >>want to read the spec :-P
> >>
> >>http://www.xml.com/pub/a/2002/08/07/deviant.html
> >>
> >>Since there has been quite a good reception on switching the documentDTD
> >>over to a profile of XHTML2wd, I think that maybe the best thing could
> >>be to make a branch, change there the DTD, check that it all works, and
> >>ask a vote for a branch switch.
> >>
> >>What do you think?
> >
> > I think that you are reading a lot into a short discussion.
>
> We have already discussed a *lot* about using XHTML modules in Forrest,
> and I understood that it was agreed to try them.
> Also, we had decided to merge all links into one, make the class
> attribute available, and look at the libre effort.
Ken, if you have the energy to explore it at this stage,
then please do.
> > We should wait until there are some DTDs available. We need
> > the next Working Draft.
>
> Why?
> We already have our DTD, we just need to change *some* tags to conform
> for now, so that the changes we have *already* decided to make are done
> in conformance to the draft.
> Since we *have* to do them soo, IMNSHO it's better to do them according
> to the spec, which is surely more near to what it will be like than our
> current DTD.
It looks to me like it is not only simple mapping
of tag names. Rather there are some structural changes
that are not yet fully decided nor described via schema/DTD.
> > Also i browsed their recent discussion
> > archives and this makes me feel that it is too early.
>
> Too early to make our DTD *similar*?
> Too early for what?
See Masayasu Ishikawa comment on the status:
http://lists.w3.org/Archives/Public/www-html/2002Aug/0119.html
They are still discussing major issues ...
* XLink and hlink ... you see the following subject
on current www-html, www-tag, xml-dev lists:
XHTML 2.0 and the death of XLink and XPointer?
http://lists.xml.org/archives/xml-dev/200208/msg00827.html
* href attribute on many different elements.
* Block elements within block elements
e.g. <p> can now contain <ul> and other block elements
All these things have big impact on our XSLT. And how
can we be "switching the documentDTD over to a profile
of XHTML2wd" when they do not yet have a DTD?
> > We need to allow time for more discussion on whether this is
> > the way to go. Some prime Forrest people are away.
>
> As I said from the start, there will be no vote till all of the Forrest
> developers can have their say, and after a good discussion.
>
> And I haven't yet heard from you.
Maybe you will, maybe not ... no time for everything.
> > When it does come time for this, is it better to experiment
> > in Forrest's scratchpad, rather than manage branches?
> > We already have some scratchpad build targets for doing
> > transformation and processing of other document types.
>
> But this is about converting all the documentation in XHTML,
> should I copy all of it in scratchapd?
That is what the scratchpad targets are doing - automated
conversion to a different document type. They will help you
to transform some current xdocs to the XHTML2wd.
If you think that the result of this conversion is best
explored in a new branch, then go for it.
Sure, the best way to explore something is to try to implement
it. Excellent if Forrest can provide them some feedback on any
implementation problems before they become concrete. I have
battles in my geospatial community because they develop
standards without trying to implement them.
> OH well, let's wait for Steven to come back even only to discuss, or the
> sky will fall...
Steady on Ken, no need for sarcasm.
--David
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>An interesting article on XHTML2, for those who don't
>>want to read the spec :-P
>>
>>http://www.xml.com/pub/a/2002/08/07/deviant.html
>>
>>Since there has been quite a good reception on switching the documentDTD
>>over to a profile of XHTML2wd, I think that maybe the best thing could
>>be to make a branch, change there the DTD, check that it all works, and
>>ask a vote for a branch switch.
>>
>>What do you think?
>
> I think that you are reading a lot into a short discussion.
We have already discussed a *lot* about using XHTML modules in Forrest,
and I understood that it was agreed to try them.
Also, we had decided to merge all links into one, make the class
attribute available, and look at the libre effort.
> We should wait until there are some DTDs available. We need
> the next Working Draft.
Why?
We already have our DTD, we just need to shange *some* tags to conform
for now, so that the changes we have *already* decided to make are done
in conformance to the draft.
Since we *have* to do them soo, IMNSHO it's better to do them according
to the spec, which is surely more near to what it will be like than our
current DTD.
> Also i browsed their recent discussion
> archives and this makes me feel that it is too early.
Too early to make our DTD *similar*?
Too early for what?
> We need to allow time for more discussion on whether this is
> the way to go. Some prime Forrest people are away.
As I said from the start, there will be no vote till all of the Forrest
developers can have their say, and after a good discussion.
And I haven't yet heard from you.
> When it does come time for this, is it better to experiment
> in Forrest's scratchpad, rather than manage branches?
> We already have some scratchpad build targets for doing
> transformation and processing of other document types.
But this is about converting all the documentation in XHTML, should I
copy all of it in scratchapd?
OH well, let's wait for Steven to come back even only to discuss, or the
sky will fall...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> An interesting article on XHTML2, for those who don't
> want to read the spec :-P
>
> http://www.xml.com/pub/a/2002/08/07/deviant.html
>
> Since there has been quite a good reception on switching the documentDTD
> over to a profile of XHTML2wd, I think that maybe the best thing could
> be to make a branch, change there the DTD, check that it all works, and
> ask a vote for a branch switch.
>
> What do you think?
I think that you are reading a lot into a short discussion.
We should wait until there are some DTDs available. We need
the next Working Draft. Also i browsed their recent discussion
archives and this makes me feel that it is too early.
We need to allow time for more discussion on whether this is
the way to go. Some prime Forrest people are away.
When it does come time for this, is it better to experiment
in Forrest's scratchpad, rather than manage branches?
We already have some scratchpad build targets for doing
transformation and processing of other document types.
--David
> Nicola Ken Barozzi wrote:
> >
> > Bruno Dumon wrote:
> >
> >> Thanks for the feedback, Nicola.
> >>
> >> When I was writing my message I was thinking about pure documentation.
> >>
> >> However, it seems that the forrest dtd should be more some kind of
> >> intermediate format between the content sources and the actual
> >> presentation. In that case, I think that it urgently needs more
> >> flexibility and features, and html is then of course the logical and
> >> appropriate choice.
> >
> >
> > Yes.
> > General documentation can be written directly via this dtd, and also
> > general content can use this, but more specific DTDs can simply use this
> > in some parts (see faq and howto DTDs) or simply use it as an
> > intermediate format (JavadocXML).
> >
> >> BTW, as for html 4 and the deprecated presentation markup: it was
> >> already removed in the strict dtd, which is the recommended one. Of
> >> course xhtml2 is still cleaner in that regard.
> >
> >
> > Yup :-)
> >
> >> On Sun, 2002-08-11 at 22:52, Nicola Ken Barozzi wrote:
> >>
> >>> Bruno Dumon wrote:
> >>>
> >>>> On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
> >>>>
> >>>>
> >>>>> XHTML2 working draft
> >>>>> http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
> >>>>>
> >>>>
> >> [big snip]
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
An interesting article on XHTML2, for those who don't want to read the
spec :-P
http://www.xml.com/pub/a/2002/08/07/deviant.html
Since there has been quite a good reception on switching the documentDTD
over to a profile of XHTML2wd, I think that maybe the best thing could
be to make a branch, change there the DTD, check that it all works, and
ask a vote for a branch switch.
What do you think?
Nicola Ken Barozzi wrote:
>
> Bruno Dumon wrote:
>
>> Thanks for the feedback, Nicola.
>>
>> When I was writing my message I was thinking about pure documentation.
>>
>> However, it seems that the forrest dtd should be more some kind of
>> intermediate format between the content sources and the actual
>> presentation. In that case, I think that it urgently needs more
>> flexibility and features, and html is then of course the logical and
>> appropriate choice.
>
>
> Yes.
> General documentation can be written directly via this dtd, and also
> general content can use this, but more specific DTDs can simply use this
> in some parts (see faq and howto DTDs) or simply use it as an
> intermediate format (JavadocXML).
>
>> BTW, as for html 4 and the deprecated presentation markup: it was
>> already removed in the strict dtd, which is the recommended one. Of
>> course xhtml2 is still cleaner in that regard.
>
>
> Yup :-)
>
>> On Sun, 2002-08-11 at 22:52, Nicola Ken Barozzi wrote:
>>
>>> Bruno Dumon wrote:
>>>
>>>> On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
>>>>
>>>>
>>>>> XHTML2 working draft
>>>>> http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
>>>>>
>>>>
>> [big snip]
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bruno Dumon wrote:
> Thanks for the feedback, Nicola.
>
> When I was writing my message I was thinking about pure documentation.
>
> However, it seems that the forrest dtd should be more some kind of
> intermediate format between the content sources and the actual
> presentation. In that case, I think that it urgently needs more
> flexibility and features, and html is then of course the logical and
> appropriate choice.
Yes.
General documentation can be written directly via this dtd, and also
general content can use this, but more specific DTDs can simply use this
in some parts (see faq and howto DTDs) or simply use it as an
intermediate format (JavadocXML).
> BTW, as for html 4 and the deprecated presentation markup: it was
> already removed in the strict dtd, which is the recommended one. Of
> course xhtml2 is still cleaner in that regard.
Yup :-)
> On Sun, 2002-08-11 at 22:52, Nicola Ken Barozzi wrote:
>
>>Bruno Dumon wrote:
>>
>>>On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
>>>
>>>
>>>>XHTML2 working draft
>>>>http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
>>>>
>>>
> [big snip]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Bruno Dumon <br...@outerthought.org>.
Thanks for the feedback, Nicola.
When I was writing my message I was thinking about pure documentation.
However, it seems that the forrest dtd should be more some kind of
intermediate format between the content sources and the actual
presentation. In that case, I think that it urgently needs more
flexibility and features, and html is then of course the logical and
appropriate choice.
BTW, as for html 4 and the deprecated presentation markup: it was
already removed in the strict dtd, which is the recommended one. Of
course xhtml2 is still cleaner in that regard.
On Sun, 2002-08-11 at 22:52, Nicola Ken Barozzi wrote:
> Bruno Dumon wrote:
> > On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
> >
> >>XHTML2 working draft
> >>http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
> >>
[big snip]
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>
>> Ross Gardler wrote:
>>
>>>> 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.
>
>
> This will give us numbering, but not the numbering I would expect. When
> I author documents I expect the sections to be numbered, not some
> relatively arbitrary text I can drop in almost anywhere. However, lets
> see how this works:
>
> <section>
> <p>A para</p>
> <h>A header/title</h>
> <p>Another para</p>
> <section>
> <p>A para in the embedded section</p>
> <h>The header/title of the embedded section</h>
> </section>
> <h>Another header/title</h>
> <p>And yet another para</p>
> </section>
>
> Would become, something like:
>
> A para
> 1. A header/title
> Another para
> A para in the embedded section
> 1.1. The header/title of the embedded section
> 2. Another header/title
> And yet another para
>
> Note how the embedded para is not clearly in the embedded section. Sure
> we could indent it to give:
>
>
> A para
> 1. A header/title
> Another para
> A para in the embedded section
> 1.1. The header/title of the embedded section
> 2. Another header/title
> And yet another para
This is what would come out, yes.
> But this still isn't what I get if I have a title available.
Hmmm, in fact this seems more like a liability than a feature...
I think that in the next they revision they would probably change it
because of this thing, so I would be +1 if we decide that the "h" tag
should be the first tag after the "section" tag.
We can block or issue a warning, either is fine for me.
>> 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.
>
> I can see this as an argument for having a <h> element but not for
> removing the <title> element. The title can only be in one place becasue
> it is only applicable in one place. Now if <section> has a title
> attribute... (are we going round in circles now?)
In XHTML every tag has a possible title element, but it works more as an
"alt" one IIUC.
As I said, it's fine if we make "h" behave like our "title" tag.
>>>> 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
>>
>> becomes
>>
>> <line>a</line><line>b</line>
>
> OK. I prefer this and would propose the same for our DTD regardless of
> the decision on XHTML2. I never did like <br/> it just doesn't behave
> like all the other elements.
+1
>>
>>>> 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.
>>
>>>> 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.
>
>
> OK, well I'll leave that for those who know about Libre then.
>
>>
>>>>
>>>> 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.
>
> I define an abstract in the same way but don;t agree that it doesn't
> need markup. I need to put references, emphasis, bold etc in my abstracts.
References are separate meta entities.
As for emphasis, it's usually not needed, and when I read abstract, from
for example medical veterinary stuff (my soon-to-be wife :-) I see only
plain text.
>> Anyway I've never seen it used, so I guess that simple text for it
>> would really be enough.
>
> Yes, that is a good point I use it becasue it is there but there is
> nothing to stop me using a <div class="abstract">
Yes, although the meta abstract is more for machine indexing
consumption, while your <div class="abstract"> is part of the page.
Since current abstract tag is in the header, I would assume the first case.
>>>> 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.
>
> It does, but it is superceded (in my view) by setions.
>> As or sup and sub, we already have them, and in some languages they
>> are part of the words (content), not presentation.
>>
>>>>> 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?!?
>> :-P
>>
>>>>> 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.
>
>
> And thereby allowing other DTD's to be used. For example, for those who
> don;t know Centipede, it takes the output from a number of other apps
> (such as JUnit), converts this output to the forrest DTD and then
> processes as normal. No problems with using an alien DTD there.
Exactly :-)
You know what I mean, since I just broke what you did on Centipede for
this ;-)
Anyway this is the goal :-)
>>>>
>>>> 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.
>
> So did the above table include all the elements in each of the modules
> you listed?
Yes. Some XHTML2 modules are missing, but for the listed ones they are
all the tags.
Oh, I forgot the Edit Module, which defines
del - deleted content, ie deprecated
ins - newly inserted content, to be approved
These would play very nicely with a CMS.
Here is the list of all the modules, with * on the ones we would use:
N/A 1. Introduction
N/A 2. Terms and Definitions
N/A 3. Conformance Definition
N/A 4. The XHTML 2.0 Document Type
N/A 5. Module Definition Conventions
* 6. XHTML Attribute Collections
* 6. XHTML Attribute Collections
* 7. XHTML Structure Module
* 8. XHTML Text Module
* 9. XHTML Hypertext Module
* 10. XHTML List Module
11. XHTML Bi-directional Text Module
12. XHTML Client-Side Image Map Module
* 13. XHTML Edit Module
* 14. XHTML Linking Module
* 15. XHTML Metainformation Module
* 16. XHTML Object Module
* 17. XHTML Presentation Module
18. XHTML Scripting Module
19. XHTML Server-Side Image Map Module
N/A 20. XHTML Style Sheet Module
* 21. XHTML Tables Module
* 22. XHTML Target Module
As you see, it's pretty all there, and 11, 12, 19 could get inside later
maybe, if we will find a need.
> Sorry I know I should read the recomendation but I'm lazy
> and I'm sure I'm not the only one on this list ;-)
Hey, it's really easy to read, honest ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: libre status (was RE: XHTML2 I have read it and I like it... GO READ IT!)
Posted by Marc Portier <mp...@outerthought.org>.
> > Taking it really off topic: (but realted)
> > What I'ld like to see (out of my league and time-schedule :-(,
> so here is an
> > itch I don't think I can scratch myself) is some doc that describes the
> > "resources" (other then the sitemap: human readable please)
> > It should be the base for thinking (and discusussing) about
> more of what we
> > want to slide into TheContract we offer.
> > (metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
> > tabs???, ...)
> >
> > It could be a basis for deviding work as well...
> >
> > If we're doing this meta-web thing (forrest) the full cocoon
> way, carefull
> > thought about the URI space we manage should be our prime concern?
>
> Yes, this is the question I wanna ask you all...
>
> Currently, we have our sources in src/documentation.
> Then we copy them to a place where they are built.
> As already said, other tool place their docs somewhere too, in the right
> format, and Forrest should be able to pick them up.
>
to help thinking: such other tools could be the cents now in centipede:
jdepend, junit test results, a locally ran kind of gump, the syntax
highlighter, the umljavadoclet, ... stuff that can't be ran in a generator
(let allone that you wouldn't want to do it)
there is a number of roles in the play
1. us forresters: we can fix all dirs and sitemap, decide which content
portions are required/optional...
I'ld like to see us do this in terms of xlayout references in stead of
fixed dirs, that would allow other ant tasks to fit in more nicely.
Drawback is that sitemap will not pick up the xlayout stuff (same problem
with the @skin@ maybe an xslt producing the sitemap is an option? )
2. project builders: actually my feeling is they should just do that: write
up all inside the ./src and nothing more
3. site publisher: the one that decides which portions of content should be
created and published, how they hook up into a navigation --> this means
editing book.xml's (or less libre configs in future) as well as editing
build.xml (??? doesn't sound right, should be more properties.xml work if
you ask me)
4. another site publisher (same cvs co published to different sites, other
skins, same relative URI spaces though): editing/overriding similar
properties in some sort of bot conf
> The problem is: where?
I would go for defined xlayout names that people can change to their need by
editing layout.xml
and make sure we have some mechanism for generating a sitemap that knows
about these 'changes/customizations'
As I mentioned to Nicola in private earlier I believe that this layout.xml
could help around in the bot as well.
Point is that if we'll going to gump-like build more stuff in one sweap
(forrest at the end of a list of cents that have generated their stuff) we
need to have a build-file flavor that allows to actually make the produced
targets available
Point is build files only make their target-names public, meaning you can
call them, and they produce whatever target you ask them (and you chain up
dependencies) but you can't get TO the target (the side effect is there, the
return type is void if you like. Build files make something, they don't
'return' something. While this is great hiding of the implementation it
makes it very hard for various more indpendent processes (cents) to actually
find and use what the other one just build.
> Which URIs are used?
I would let this lead the discussion. rest should follow...
maybe we can list what we have/want and drop in suggested URI-names?
list of haves is:
- dtdx
- xdocs
- faq
- status page (todo)
- changes
up to the wants?
- syntax highlight source code
- maillist archive
- javadoc with uml via xdoc
- books of assembled file snips
- ...
I know Steven started off an ambitious idea on having content aware
pipelines on cocoon-dev, which will surely produce some usefull stuf, but
that doesn't mean we should be (in the mean time) throwing all types of
files just in a big heap and then just see what happens, right?
To organize this out, we have plenty of flexibility in 3 places:
1. defining the url to get it (*.dtdx.html is a good example, the faq could
use the same no?)
2. the navigation (book.xml and overly promised successor)
3. organize/decide where to store it on disk
there is mappings available between them, so we get the nice SoC everyone
likes?
(the content-aware pipelines would make the choice of DTD for a document a
4th flexibility parameter)
(come to think of it, this sounds as enough flexibility so we pretty much
should be able to start off without user definable xlayout dirs if you ask
me, it's just that they are in cvs and more thight to the project using
centipede then to using forrest, meaning people will consider changing it
based on centiped use, and drwan back by forrest possibly not letting them?)
Nicola, I guess centipede would suggest its users to change their layout.xml
at will, right?
> How do we link (also with libre...)
> :-?
Should follow from the full request namespace.
The top down linking with book or libre should be fairly ok I guess, the
cross refs between te docs are the ones that come under the realm of actual
editors... and that's a bit more nasty... starting to think about something
like layout.xml again, and references that can be looked up there?
-marc=
PS: Have been looking at how some of my messages end up on the list...
As a big sorry for all the typos in past and future mails, I should let
you know I have a great mentor in this:
http://www.brainyquote.com/quotes/quotes/a/q138608.html and
http://home.freeuk.com/elloughton13/aamilne.htm for more
Re: libre status (was RE: XHTML2 I have read it and I like it...
GO READ IT!)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marc Portier wrote:
>>>>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.
>>
>>OK, well I'll leave that for those who know about Libre then.
>
> In 2 words libre should produce the structure xml (parts of) that is now
> skattered over the book.xml-s
>
> since it's program produced, it should be less of a hastle to have it say
> something else then change all stuf in the book.xml here and there. In
> other words I don't really give that much about it, somewhere down the line
> we'll have to think about the elms and @atts we're going to use to depict
> this structure. My guess now is that this would be something that can be
> used as much towards html as to e.g. a toc (towards pdf) in which case it
> would probably also be base towards an xml format that aggregates
> (cinlcudes) all into a book or something (dreamin' out loud)
Yes :-D
> Taking the opportunity to give a status update:
> - Bit set off by other work ATM, still reading and thinking about libre
> though
> - dunno when, but will continue that
> - the more sideline talks we have about what we like to do, the more I learn
> - to my feeling the current scratchpad contrbution is nothing more then a
> first prototype
>
> looking at the lack of adoption it surely lacks the out of the box ease of
> use it should get
> Still hoping thought for others to state opinions on the thing...
Yes, the main thing is that it's not so easy to understand-use.
> Taking it really off topic: (but realted)
> What I'ld like to see (out of my league and time-schedule :-(, so here is an
> itch I don't think I can scratch myself) is some doc that describes the
> "resources" (other then the sitemap: human readable please)
> It should be the base for thinking (and discusussing) about more of what we
> want to slide into TheContract we offer.
> (metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
> tabs???, ...)
>
> It could be a basis for deviding work as well...
>
> If we're doing this meta-web thing (forrest) the full cocoon way, carefull
> thought about the URI space we manage should be our prime concern?
Yes, this is the question I wanna ask you all...
Currently, we have our sources in src/documentation.
Then we copy them to a place where they are built.
As already said, other tool place their docs somewhere too, in the right
format, and Forrest should be able to pick them up.
The problem is: where?
Which URIs are used?
How do we link (also with libre...)
:-?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
libre status (was RE: XHTML2 I have read it and I like it... GO READ IT!)
Posted by Marc Portier <mp...@outerthought.org>.
> >> 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.
>
> OK, well I'll leave that for those who know about Libre then.
In 2 words libre should produce the structure xml (parts of) that is now
skattered over the book.xml-s
since it's program produced, it should be less of a hastle to have it say
something else then change all stuf in the book.xml here and there. In
other words I don't really give that much about it, somewhere down the line
we'll have to think about the elms and @atts we're going to use to depict
this structure. My guess now is that this would be something that can be
used as much towards html as to e.g. a toc (towards pdf) in which case it
would probably also be base towards an xml format that aggregates
(cinlcudes) all into a book or something (dreamin' out loud)
Taking the opportunity to give a status update:
- Bit set off by other work ATM, still reading and thinking about libre
though
- dunno when, but will continue that
- the more sideline talks we have about what we like to do, the more I learn
- to my feeling the current scratchpad contrbution is nothing more then a
first prototype
looking at the lack of adoption it surely lacks the out of the box ease of
use it should get
Still hoping thought for others to state opinions on the thing...
Taking it really off topic: (but realted)
What I'ld like to see (out of my league and time-schedule :-(, so here is an
itch I don't think I can scratch myself) is some doc that describes the
"resources" (other then the sitemap: human readable please)
It should be the base for thinking (and discusussing) about more of what we
want to slide into TheContract we offer.
(metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
tabs???, ...)
It could be a basis for deviding work as well...
If we're doing this meta-web thing (forrest) the full cocoon way, carefull
thought about the URI space we manage should be our prime concern?
regards,
-marc=
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Ross Gardler <rg...@wkwyw.net>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>
>>> 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.
This will give us numbering, but not the numbering I would expect. When
I author documents I expect the sections to be numbered, not some
relatively arbitrary text I can drop in almost anywhere. However, lets
see how this works:
<section>
<p>A para</p>
<h>A header/title</h>
<p>Another para</p>
<section>
<p>A para in the embedded section</p>
<h>The header/title of the embedded section</h>
</section>
<h>Another header/title</h>
<p>And yet another para</p>
</section>
Would become, something like:
A para
1. A header/title
Another para
A para in the embedded section
1.1. The header/title of the embedded section
2. Another header/title
And yet another para
Note how the embedded para is not clearly in the embedded section. Sure
we could indent it to give:
A para
1. A header/title
Another para
A para in the embedded section
1.1. The header/title of the embedded section
2. Another header/title
And yet another para
But this still isn't what I get if I have a title available.
> 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.
I can see this as an argument for having a <h> element but not for
removing the <title> element. The title can only be in one place becasue
it is only applicable in one place. Now if <section> has a title
attribute... (are we going round in circles now?)
>
>>> 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
>
> becomes
>
> <line>a</line><line>b</line>
OK. I prefer this and would propose the same for our DTD regardless of
the decision on XHTML2. I never did like <br/> it just doesn't behave
like all the other elements.
>
>>> 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.
>
>
>
>
>>> 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.
OK, well I'll leave that for those who know about Libre then.
>
>>>
>>> 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.
I define an abstract in the same way but don;t agree that it doesn't
need markup. I need to put references, emphasis, bold etc in my abstracts.
> Anyway I've never seen it used, so I guess that simple text for it would
> really be enough.
Yes, that is a good point I use it becasue it is there but there is
nothing to stop me using a <div class="abstract">
>>> 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.
It does, but it is superceded (in my view) by setions.
>
> As or sup and sub, we already have them, and in some languages they are
> part of the words (content), not presentation.
>
>>>> 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?!?
> :-P
>>>> 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.
And thereby allowing other DTD's to be used. For example, for those who
don;t know Centipede, it takes the output from a number of other apps
(such as JUnit), converts this output to the forrest DTD and then
processes as normal. No problems with using an alien DTD there.
>>>
>>> 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.
So did the above table include all the elements in each of the modules
you listed? Sorry I know I should read the recomendation but I'm lazy
and I'm sure I'm not the only one on this list ;-)
Ross
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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
becomes
<line>a</line><line>b</line>
>> 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)?
Yes.
>>
>> 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?!?
:-P
>>>> 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 xml.apache.org
>>> 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
> xml.apache.org 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.
Yup.
>>>> 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Ross Gardler <rg...@wkwyw.net>.
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?
> 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)
> 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?
> 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?
>
> 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? 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.
> 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?
>>> 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!
>>> 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.
>
>> 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 xml.apache.org
>> 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
xml.apache.org 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.
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?
Ross
>
>>> When Steven comes back from vacation I wanna give a vote on this,
>>> because it's really COOL:-D
>>
>
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bruno Dumon wrote:
> On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
>
>>XHTML2 working draft
>>http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
>>
>>
>>Look at this XHTML2 snippet, and see if it looks familiar:
>>
>><body>
>><h>This is a top level heading</h>
>><p>....</p>
>><section>
>> <p>....</p>
>> <h>This is a second-level heading</h>
>> <p>....</p>
>> <h>This is another second-level heading</h>
>> <p>....</p>
>></section>
>><section>
>> <p>....</p>
>> <h>This is another second-level heading</h>
>> <p>....</p>
>> <section>
>> <h>This is a third-level heading</h>
>> <p>....</p>
>> </section>
>></section>
>>
>
> Doesn't look entirely familiar to me. I see a section which can have two
> titles, and the first title is not in the beginning of the section.
> Strange. Usually, in the rendered version of a document, the title is
> the only means to identify that a new section starts. And if there are
> two titles for one section, how will they be numbered?
It's a heading, not a title. It has a slightly different meaning.
But I concede that there is a difference, though I don't really know if
it's an issue or feature.
>>There is also a del and an ins elements that can denote parts of the
>>document that are deprecated or drafts
>>http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-edit.html
>>
>>
>>
>>Then the meta module
>>(http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-meta.html) for:
>>
>> <head profile="http://www.acme.com/profiles/core">
>> <title>How to complete Memorandum cover sheets</title>
>> <meta name="author" content="John Doe"/>
>> <meta name="copyright" content="© 1997 Acme Corp."/>
>> <meta name="keywords" content="corporate,guidelines,cataloging"/>
>> <meta name="date" content="1994-11-06T08:49:37+00:00"/>
>> </head>
>>
>>It will also have a schema, and has just one module for presentation
>># 17. XHTML Presentation Module
>>
>> * 17.1. The hr element
>> * 17.2. The sub element
>> * 17.3. The sup element
>>
>>With hr element deprecated.
>>
>>Now, I really like this. It's bascally a standard version of our
>>document DTD.
>
>
> I have the impression that there are a lot of differences:
>
> - documentv11 is still a *lot* simpler than xhtml2, meaning that it is:
> - simpler to learn
> - less work to write stylesheets
> - more restrictive, thus less ways to do dirty hacks
It's not true. I never talked about implementing the *whole* spec.
Also, since html is *extremely* more known, XHTML2 is simpler to learn.
Think about link versus a... besides, in some ways documentDTD is
already more difficult than xhtml (links).
This is the concrete comparisons of the XHTML2 modules we should need
(forms left out for now), please comment on the tags themselves:
'-----------------'---------------------------------------'
| 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
code code
dfn * (requested by users via dictionary links)
div footer, legal (requested by skinners)
em em
h title
kbd * (needed, currently we misuse "code" instead)
line br
p p
| fixme (with class attribute)
| note (with class attribute)
| warning (with class attribute)
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
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)
XHTML Presentation Module
hr *
sub sub
sup sup
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.
>(think of html tags for
> scripts, objects, forms, css, image maps, ...).
We don't have to use all modules, and in fact we wouldn't.
- Scripts we keep out.
- Css is in the skin.
- image-maps, we should support them in the future, but they can keep
out for now
- objects, it's images and SVG, which we *do* support
- forms is something we miss that we need. Look at the simple fact that
we needed them for a mail form and couldn't do it OOTB.
> - documentv11 is in our hands, so it can be tailored towards our needs.
XHTML is extensible, with span and div tags, but usually a class
attribute suffices.
Anyway, we can add our tags if it's *so* important, but ATM it's really
not needed.
> - 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.
>>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.
>>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.
> 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 xml.apache.org
> 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
>>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.
>>When Steven comes back from vacation I wanna give a vote on this,
>>because it's really COOL:-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XHTML2 I have read it and I like it... GO READ IT!
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2002-08-09 at 23:44, Nicola Ken Barozzi wrote:
> XHTML2 working draft
> http://www.w3c.org/TR/2002/WD-xhtml2-20020805/Overview.html#toc
>
>
> Look at this XHTML2 snippet, and see if it looks familiar:
>
> <body>
> <h>This is a top level heading</h>
> <p>....</p>
> <section>
> <p>....</p>
> <h>This is a second-level heading</h>
> <p>....</p>
> <h>This is another second-level heading</h>
> <p>....</p>
> </section>
> <section>
> <p>....</p>
> <h>This is another second-level heading</h>
> <p>....</p>
> <section>
> <h>This is a third-level heading</h>
> <p>....</p>
> </section>
> </section>
>
Doesn't look entirely familiar to me. I see a section which can have two
titles, and the first title is not in the beginning of the section.
Strange. Usually, in the rendered version of a document, the title is
the only means to identify that a new section starts. And if there are
two titles for one section, how will they be numbered?
>
> There is also a del and an ins elements that can denote parts of the
> document that are deprecated or drafts
> http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-edit.html
>
>
>
> Then the meta module
> (http://www.w3c.org/TR/2002/WD-xhtml2-20020805/mod-meta.html) for:
>
> <head profile="http://www.acme.com/profiles/core">
> <title>How to complete Memorandum cover sheets</title>
> <meta name="author" content="John Doe"/>
> <meta name="copyright" content="© 1997 Acme Corp."/>
> <meta name="keywords" content="corporate,guidelines,cataloging"/>
> <meta name="date" content="1994-11-06T08:49:37+00:00"/>
> </head>
>
> It will also have a schema, and has just one module for presentation
> # 17. XHTML Presentation Module
>
> * 17.1. The hr element
> * 17.2. The sub element
> * 17.3. The sup element
>
> With hr element deprecated.
>
> Now, I really like this. It's bascally a standard version of our
> document DTD.
I have the impression that there are a lot of differences:
- documentv11 is still a *lot* simpler than xhtml2, meaning that it is:
- simpler to learn
- less work to write stylesheets
- more restrictive, thus less ways to do dirty hacks
- documentv11 is more device-independent (think of html tags for
scripts, objects, forms, css, image maps, ...).
- documentv11 is in our hands, so it can be tailored towards our needs.
- xhtml2 is not here yet, there's only a very rough first draft, there's
not even a schema or DTD for it.
>
> 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.
> 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).
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 xml.apache.org
documentation, so the primary DTD should be one tailord towards
documenting software (but could be html-alike, like it is today).
> 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 :-)
> When Steven comes back from vacation I wanna give a vote on this,
> because it's really COOL:-D
>
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org