Re: [jats-list] Automated object numbering, and empty <xref>s to objects (Archiving v3).

Subject: Re: [jats-list] Automated object numbering, and empty <xref>s to objects (Archiving v3).
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 08 Sep 2011 16:03:35 -0400
Dear Simon,

On 9/7/2011 9:06 AM, Newton, Simon - Edinburgh wrote:
(1) It seems from the element reference page for <chem-struct-wrap>
that one could omit explicit labels because "A <chem-struct-wrap>  may
also be numbered, automatically by a formatting application or by
preserving the number inside a<label>  element." Having seen this,
but not found similar comments about "automatic numbering" for other
elements that may typically be numbered/labelled, I would like to
know what the assumption is about omitting labels in general for
these (e.g. chemical structures, equations, figures, tables, etc.):
is a formatting application expected by default to generate a
number/label? If so, is there a way to suppress numbering for some
occurrences?

I don't think any assumptions are made regarding when and exactly how numbering should be automated; there is only a recognition that it commonly done in publishing systems, and JATS is designed to support this (or no numbering at all) or not, depending on local policies.


Neither is there any expectation that by default, a formatting application will number things.

This means you have both the opportunity and the burden to define a policy that makes the most sense for your data and workflow.

If you do want numbering to appear only sometimes, but do not want to enhance JATS with switches for turning it off, that does suggest you should have a policy that numbering is *not* to be automatically generated.

The JATS preview stylesheets that Mulberry wrote try to accommodate different purposes here: as delivered, they do not automatically number things, but numbering can be switched on in the stylesheet. (There is one exception: as delivered, ref elements *are* automatically numbered unless there are *any* ref elements with labels, in which case numbers are not generated for any of them.)

But this design was not intended as and shouldn't be taken as a recommendation in any way; on the contrary, we did it this way only because we had to do it some way, while being aware that no way we did it would be correct for everyone.

(2) Relatedly, what is the expected behaviour for
an <xref> element that has no content (e.g. one that (a) references
an element for which automatic numbering has been assumed and which
therefore lacks a<label>, or (b) one that references an element
possessing a <label>)?

You need a policy for this too, coordinated with your first policy.


Again, the preview stylesheets try to thread a needle here. For an empty xref, a label is fetched from the target if there is one; if not, if a label is being generated for the target element, it is used (with its number if there is one). As a fallback, a warning text is shown, saying no label was available. (This is after all a preview stylesheet so an ugly warning serves a quasi-validation function.)

I have seen publishing systems (both JATS-based and not) with all kinds of different policies for numbering, whose rationales have been more or less well considered.

One system I help with (not JATS-based but for these purposes it may as well be) has recently decided to roll back the automatic numbering and encode labels explicitly where (and only where) numbers are wanted. (These can and will be automatically generated in the source data during editorial phase.) This decision was made for two reasons. First, we wanted to ensure stability in numbering for citation purposes, both the numbers themselves and their format, especially since in this instance even paragraphs are numbered; plus papers are sometimes subject to post-publication revisions, which sometimes have to be transparent and which have the potential of disrupting numbering. And secondly -- essentially the reason you cite -- it turns out that (especially in the case of paragraphs) the rules regarding which things get numbered and which things don't were becoming complex, which made for problems both for maintenance (ensuring consistency across publishing platforms) and when human intervention was needed.

Regards,
Wendell

--
======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread