Re: [jats-list] Element for wrapping a group of xref elements

Subject: Re: [jats-list] Element for wrapping a group of xref elements
From: Kaveh Bazargan <kaveh@xxxxxxxxxxxx>
Date: Tue, 5 Feb 2013 23:44:49 +0000
Hello Wendell

Thank you for the post, raising important issues. I have been
wondering whether the JATS list is the right place to discuss some of
these issues, and I think it is. Comments below:


[...]

> On Sat, Feb 2, 2013 at 4:19 PM, Kaveh Bazargan <kaveh@xxxxxxxxxxxxxxxx> wrote:
> > I do take your points, but I would say that most of these can be
> > auto-generated by putting an attribute in the XML, which is then
> > passed to the pagination system which generates the correct visual
> > output. See for instance the natbib package for TeX:
> >
> > http://merkel.zoneo.net/Latex/natbib.php
>
> I agree with you that logic like this is possible and indeed not
> terribly difficult to implement given available tools. (In fact,
> although an xref wrapper element might make some things a bit easier,
> this logic can be done even with the current JATS model, given a
> strong enough specification of inputs. It's the last part that's key.)
>
> Yet as you know, the deeper question is whether publishers can have
> the advantages of retooling to take advantage of this potential, while
> at the same time doing things the way they've always been done, both
> with respect to editorial process and workflow, and with respect to
> look-and-feel of the presentation.

That is a very good point. I think that we should aim to have the best
of both worlds. I would argue that some of the things publishers have
traditionally done has been because the medium of communication has
been paper. This has changed only in the last few years. From my
experience, publishers are still too entrenched in the old ways.
Things will change, but I want to hasten that change. ;-)

>
> > I would also suggest that the traditional forms for citations are a
> > legacy of the print days. If most people are reading electronically
> > perhaps we should change the way we show refs in PDFs, because full
> > info can be obtained by hovering over the reference.
> >
> > In any case at the very least we can put the correct labels for
> > author/year, as we are now, but have the option of creating numerical
> > refs instead.
>
> True, and this also goes to the point: "if most people are reading
> electronically" is still a big if, especially considering the broadest
> range of applications and users and the longest time frames.
>
> Then too, XML is often sold as a "both/and" technology ... and indeed
> I believe that even in the present case, a both/and solution -- a
> workable common ground between traditional and new --  is often
> possible. It just might not be possible in the general case, given how
> extreme both "traditional" and "new" can be.
>
> In other words, I'm with you all along the way as long as we're
> talking about implementing a particular system for a particular
> publisher, who can make assessments and judge risks and rewards for
> themselves. When it comes to recommending, instituting or enforcing a
> community or industry standard -- maybe not so much.

OK. But let us at least enlighten and encourage those publishers who
are not using the correct procedures, to move with the times. The
sooner they do, the less conversion of legacy data they will have to
endure.

Everyone talks about an XML-first workflow, but when you look at the
details, it is not true automated XML first. I think that it is
possible to have a true XML first workflow *and* preserve all
typographic and conventional niceties. If you will forgive my self
publicity, you can see a demo of such a workflow at minute 13 of this
video:

http://river-valley.tv/xml-is-not-just-a-format-its-much-much-more/


[...]

> > Well, if authors realised what they can gain by assisting the
> > production of a fully structured document (e.g. text mining, reading
> > by the blind), I think they perhaps they would be happy to lose a
> > little of tradition in prose... The problem is that most authors have
> > no idea of what can be done. Publishers don't help, by hiding their
> > XML in "archives", and not publishing them even to subscribers. ;-)
>
> Again, it's a big if. I'll suggest we reword this and say "when
> authors realize what they can gain..." etc. And agree wholeheartedly.
>
> But in many places, that day is not here and may be slow in coming.
>
> I do believe that publishers can lead; but I also think a "standard"
> does better to follow.

This is where we can debate. ;-)

If publishers are using bad practices (and a lot are), do we just
follow those practices and give them tools to continue? Should we not
at least alert or encourage them towards better, more future-proof
ways?

>
> Then too, when that day is here -- authors won't be writing what they
> write now, but something different. (Maybe better in many ways, but
> different.) In the meantime, keep in mind that authors too are
> designers, just as are layout and production people. All of us have
> notions of the right way to do it -- in fact we will know that day is
> here when authors start besieging publishers with feature requests to
> be sorted, reconciled and prioritized, presenting an entirely new
> problem.
>
> Given this, I think much of the effort given to reform other people's
> practice (by means of standards development or other activities) might
> be better spent in demonstrating what can be done, exposing how it is
> done (again I agree with you), and making it easier for others to
> emulate.

I think we are more or less agreed then. :-)

>
> You can't force the donkey to eat the carrot!

What a nice quote. I will re-use that.

But we can sweeten the carrot so much they can't resist. That should
be our task. :-)


--
Kaveh Bazargan
www.river-valley.com | www.river-valley.tv | www.bazargan.org

Current Thread