On 11.06.2009, at 00:44, Jonas Sicking wrote:
On Wed, Jun 10, 2009 at 3:12 AM, Julian
Reschke<[email protected]> wrote:
Ian Hickson wrote:
...
So far based on my experience with the Workers, Storage, Web
Sockets, and
Server-sent Events sections, I'm not convinced that the advantage
of getting
more review is real. Those sections in particular got more review
while in
the HTML5 spec proper than they have since.
...
So you are putting stuff you're personally interested in into the
HTML5
spec, so that people read it?
Calling it stuff Ian is "personally interested in" seems unnecessarily
inflammatory. This are all use cases that other people have put
forward.
However, as others, I'd prefer to see these things developed
elsewhere. Mostly because the group of people with expertise in
developing a better version of bibtex is not the people in this WG.
I completely agree with this conclusion. I also think that it would be
a big mistake to include bibtex and then extend it later as Ian has
suggested.
Let me give a concrete example, take the following biblipgraphic
entry: Doe, John: Foreword. In: Doe, Jane: The Book. Middle-Earth 2008.
What we have here is a chapter by an author in a book by someone else.
This someone else is not the editor though, but the author of the
book, This kind of text is fairly common in my field but it cannot be
expressed in bibtex since bibtex originally only has fields for
'author' and 'editor ', but not for 'bookauthor'.
According to Ian, something like this could be covered by extending
the bibtex vocabulary. For me, two problems pop up here:
Who will decide how the vocabulary gets extended? And on what will
these decisions be based?
Now lets say that some kind of process to extend the bibtex vocabulary
can be established and that the addition of a 'bookauthor' field will
be decided. The problem then is that something gets added to bibtex
which no existing bibtex style (and no other tool which can import
bibtex) knows about. AFAIK only biblatex has a 'bookauthor' field. In
other words: We then have data which is not useable with the
traditional bibtex tools (they don't break, they just wont process
the new fields). If bibtex gets extended (which would be absolutely
necessary since all kind of additional fields are needed), we
unavoidably end up with some kind of superbibtex which no tool in the
world can process. In other words: We then have a new format which
looks like bibtex but which cannot be used in a traditional bibtex
workflow. At this point the whole argument why bibtex should be used
in this spec breaks down. Ian is in favor of bibtex because it is
widely used; but if we unavoidably end up with an unuseable
superbibtex, this argument becomes moot.
If compatibility to existing formats is the main objective, we simply
can't extend an old format like bibtex. If the goal is to cover
substantially more than bibtex does, we need a different format.
Simon
--
Simon Spiegel
Steinhaldenstr. 50
8002 Zürich
Telephon: ++41 44 451 5334
Mobophon: ++41 76 459 60 39
http://www.simifilm.ch
„In a world getting more and more democratic, film directing is the
last resort for dictators.“ Francis Ford Coppola
