Re: Decentralized poetry markup (language) (ISSUE-41)

Leif Halvard Silli:
> Dr. Olaf Hoffmann, Wed, 20 Jan 2010 11:37:20 +0100:
> > The vocabulary collection for literature markup exists,
> > a complete specification too:
> > http://purl.oclc.org/net/hoffmann/lml/
> >
> > If there is a real interest to extract some subset applicable for
> > an integration in (X)HTML with some noticable and usable final
> > result, this would be fine and if required and requested I could help ;o)
> > On the other hand, I have not much interest to write yet another
> > wiki-page, specification, proposal, whatever, just  as a personal
> > occupational therapy ;o)
>
> The spec writer/proposer is usually a driving force, I think, in such
> efforts. The point with a separate spec is that those that are
> interested in it can develop it, whereas those that are against it can
> be somewhat sidelined.
>

If we assume for a moment, that this will happen, immediately
other questions appear.

I think with the new semantical elements already in the HTML5
draft (section, article, dialog, header, footer etc) Ian Hickson had 
some careful and thought through efforts to get some level of 
graceful fallback, at least if the author of a document is able to 
create some meaningful structure. 

If you start to write this for some larger amount of semantical issues,
this will not be possible anymore. If the collection of already known
HTML elements as for poetry is effectively empty, there will be no graceful 
fallback. LML is done from scratch, already more a replacement for 
the semantical fraction of (X)HTML than an extension. 
The only possible fallback for such an extension of (X)HTML
are maybe some hints to authors to provide always a complete 
stylesheet collection for those elements - and this works only, 
if the old user-agent has some XML-like general understanding of an 
unknown but stylable element.
As far as I know, this is not the case for all old browsers. I do not know
at all, what happens with unknown elements in screen-readers or
other specific devices and if they have an option for authors to
provide some stylable fallback.
Therefore authors taking care of users with problematic browsers will either
have to use the application/xhtml+xml variant of HTML5 (what is not
available too for some old browsers) or will have to wait some more 
years after the recommendation appears, to be relatively sure, that 
there is an acceptable default presentation.
If this is a show-stopper for the old fashioned text/html variant of
HTML5, it is questionable, if it is worth to start with it, because for
the application/xhtml+xml variant you can start to mix it right now
without further specification action.

Already XHTML2 was considered to be too progressive and it had
only a few more elements in a comparable amount as HTML5
has - what can we expect for a specification with 40 to 80 more
semantical elements designed from scratch? ;o) Yes, what
can we realistically expect, if even these relatively fallback
friendly HTML+RDFa attempts create so much noise in this group?

And even if we assume, all this is ok and (X)HTML will finally 
start into the new millennium with this - which parts of LML
should be considered to be imported into a text/html draft?
Just poetry? Specific markup for prose too? For more
technical literature? The advanced approach for 
meta information? Just a patch or a real attempt to
get it usable as a whole in five or ten years?


> > Therefore if there is no common aim to really extend (X)HTML
> > with some more semantics,
>
> It doesn't look like poem elements will be making it to the HTML5
> language spec, no. But that doesn't mean that it would be pointless to
> have a text/HTML spec for it. In accordance with what Henri said [1]:
> To most people it is more important that it is considered valid HTML
> than it is that it is considered part of the very HTML5 language spec.
>

As already mentioned too, what valid means becomes quite relative in
these days, especially because the W3C validator already produces
obvious nonsense for some new formats, authors cannot rely on it
anymore.
The current 'monster-draft' for HTML5 is far too complex to check it
manually either. Seems like the text/html tag soup drama will have an
endless continuation. And neither validators nor the HTML5 draft will
save us.

> > I recommend using html:div and html:span
> > together with the already existing LML vocabulary with a role mechanism
> > or with RDFa (or an equivalent mechanism to provide relations to other
> > vocabularies). This requires almost no extra work on drafts to what seems
> > to be already work in progress in the current HTML5 drafts and is already
> > applicable within SVG tiny 1.2 and the XHTML+RDFa recommendation.
>
> This started with your reaction against a certain mark-up of a poem in
> a specification draft. It doesn't look like poem mark-up will make it
> into the HTML5 language spec. But at the very least text/HTML needs a
> better way to mark up poems if that is supposed to be improved.
>

Sure. I think, Steve has several options to solve/avoid the delicate problem,
for example:
- no poetry at all
- using section and div and a role mechanism or RDFa pointing to DAISY poetry 
elements or LML
- using the application/xhtml+xml variant of HTML5 mixed with another format
like DAISY or LML to markup the poem.

If not specified, there cannot be a simple example ;o)
If the current drafts are not intended for poetry there is no need for such an
example and concerning the problem with the img+alt this can be simply
replaced with for example a combination of a 'flash fiction' and  an image or
something like this. This can be represented with section and p etc without
major problems.

Olaf



> [1] http://www.w3.org/mid/C695B929-C1CD-483B-895A-D1D176CAC89F@iki.fi

Received on Wednesday, 20 January 2010 19:12:56 UTC