Re: [jats-list] JATS revision request: add @id to front, body, and back

Subject: Re: [jats-list] JATS revision request: add @id to front, body, and back
From: Tommie Usdin <btusdin@xxxxxxxxxxxxxxxx>
Date: Sun, 25 Nov 2012 01:29:27 -0500
Hi Kevin --

With my JATS committee hat on  no, I don't have a JATS committee hat at the
moment  I had one before and I hope to have one again  so, I can answer as
former co-chair of the JATS committee and someone who hopes-to-be-involved in
future JATS committee work, I have just summarized the problem.

The challenge is that JATS revisions now need to go through a NISO process,
and NISO (like every standards organization I know of) has some time-consuming
overhead. In this case, the JATS standard has been identified as a "continuous
maintenance" standard, which means that changes can be made as needed.
However, the committee needed to do the maintenance has not yet been formally
created (so far as I know) and after it is there will have to be meetings to
discuss options, at least one draft for committee review, and then votes at
the committee and NISO level before anything can be added to the JATS.

However, speaking strictly as a user of the JATS (with no committee hat on),
this seems to me like an obvious add as soon as there is a group to consider
it. I say this because there is a user with a real need for it, it doesn't
conflict with anything I am aware of in the current specification, and I can't
imagine that adding optional IDs could possibly hurt anyone who doesn't want
them. So, my advice is to use the parameter entity mechanism to add these IDs
for your use (don't hack the DTD, customize it as it was designed to be
modified).

-- Tommie


On Nov 21, 2012, at 4:51 PM, Kevin Hawkins
<kevin.s.hawkins@xxxxxxxxxxxxxxxxxx> wrote:

> Hi folks who decide on these things,
>
> Could you say when this request will be considered and, if accepted, when a
release of JATS including this might be made?  We've got some development
coming up in early 2013 that will depend on this being in the standard or us
at least knowing that it's been accepted (in which case we'd hack a DTD in the
meantime).  Thanks,
>
> Kevin
>
> On 10/18/2012 2:38 PM, Kevin Hawkins wrote:
>> Hello,
>>
>> At JATS-Con we were asked to submit bugs and feature requests for JATS
>> to this list now rather than waiting for waiting for the continuous
>> maintenance process to be set up. So on behalf of my colleagues at the
>> University of Michigan Library, I am requesting the addition of id= to
>> <front>, <body>, and <back>.
>>
>> In constructing http://www.lib.umich.edu/mpach , we will be storing JATS
>> documents -- plus embedded media, supplemental material, and optionally
>> a user-provided typeset PDF -- with a METS "wrapper" in the HathiTrust
>> repository. HathiTrust METS files include a <structMap> pointing to the
>> salient structural features of the digital object (each identified with
>> a unique ID), which allows for traversal of the item in the interface.
>> We want to be able to point not only to each <sec> but also to <front>
>> and to any text in a <body> or a <back> which might lack <sec>s inside
>> it. We also need these IDs for fulltext indexing surposes so that all
>> PCDATA within a JATS document has a parent element with an ID. Adding
>> id= to <front>, <body>, and <back> will ensure this condition.
>>
>> Frankly, we think that it would be best to make id= a global attribute.
>> While Debbie explained to me during JATS-Con that making it not global
>> was an attempt to avoid what was thought of as a mistake in the design
>> of TEI and DocBook, we feel that you can't really decide in advance what
>> use cases users will have for putting an id= on an element, even if the
>> element can only occur once according to the DTD.
>>
>> Please let me know if you have any questions,
>>
>> Kevin
>

======================================================================
B. Tommie Usdin                        mailto:btusdin@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                           Phone: 301/315-9631
Suite 207                                    Direct Line: 301/315-9634
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread