please add volume and issue number to output from ATOM feed.

[2858] provides access to the data

the volume/issue from a Fedora Article doesn't have a structured place in an Atom feed. is there a conflation of tools, e.g. the new RSS tool produces straight Atom feeds for direct usage, no transformation. the original RSS tool produced XML which was transformed.

I think what is being asked for here the ability to provide Article volume/issue in an XML export tool from PLoS ONE for feeding into other sources like Google Scholar. as this is an enhancement, it is being moved to 0.8

also suggest that we provide a full OpenURL as part of this?

argh. we need an XML feed that we can transform as necessary in addition to the atom feed.

the previous tool provided BOTH RSS and more complete XML versions of the articles, so this is not an enhancement.

in addition to google scholar, we also use the full XML output of the RSS tool to generate email alerts.

we need this feature (or we need to keep the old RSS tool working) in 0.7.

I talked to Russ and found out that what he means by XML is the raw XML the old article service returned (before we run an XSLT on it to convert to RSS). We had an option in the old RSS tool to not run any XSLT on it and to save it as an XML. The question is if the ATOM feed being returned contains all the information the old raw XML did and if it does, then this is not an issue. Russ is oing to put an example of the XML here and we can compare it to the ATOM feed.

okay, maybe i'm overreacting, and my main issue is with the generic XML feed and not the volume and issue.

i'll move this back to 0.8, take a look at the differences between the RSS and XML outputs of the current RSS tool, and make a new ticket listing any items we need to see in the new feeds to support current processes.

thanks!

There is a dependency on #70 and #99

We need to add proprietary extensions to the ATOM feed to allow for this. From the ATOM specification:

6.  Extending Atom

6.1.  Extensions from Non-Atom Vocabularies

   This specification describes Atom's XML markup vocabulary.  Markup
   from other vocabularies ("foreign markup") can be used in an Atom
   Document.  Note that the atom:content element is designed to support
   the inclusion of arbitrary foreign markup.

6.2.  Extensions to the Atom Vocabulary

   The Atom namespace is reserved for future forward-compatible
   revisions of Atom.  Future versions of this specification could add
   new elements and attributes to the Atom markup vocabulary.  Software
   written to conform to this version of the specification will not be
   able to process such markup correctly and, in fact, will not be able
   to distinguish it from markup error.  For the purposes of this
   discussion, unrecognized markup from the Atom vocabulary will be
   considered "foreign markup".

6.3.  Processing Foreign Markup

   Atom Processors that encounter foreign markup in a location that is
   legal according to this specification MUST NOT stop processing or
   signal an error.  It might be the case that the Atom Processor is
   able to process the foreign markup correctly and does so.  Otherwise,
   such markup is termed "unknown foreign markup".

   When unknown foreign markup is encountered as a child of atom:entry,
   atom:feed, or a Person construct, Atom Processors MAY bypass the
   markup and any textual content and MUST NOT change their behavior as
   a result of the markup's presence.

   When unknown foreign markup is encountered in a Text Construct or
   atom:content element, software SHOULD ignore the markup and process
   any text content of foreign elements as though the surrounding markup
   were not present.

We need to do this to ensure we can place more proprietary elements within the feed as needed. Please note: it is very possible that this will cause some NON-CONFORMING READERS TO BREAK. This is a very likely side effect of this feature requested and we will not be able to test every reader out there to confirm.

We need to do couple things:

• Assign a namespace for proprietary extensions to ATOM for PLoS. Recommend we use http://www.plos.org/atom/ns#
• Define and document the two elements for starters:
  • plos:volume
  • plos:issue

Please let us know.

i don't think it makes sense to extend the atom spec for this enhancement.

let's include these items in the XML representation of the feed (PLoSRESTDevGuide discusses the 'representation' parameter)

we've got a lot of things that don't fit into the atom spec that we're going to want to access through REST. the XML output from the old RSS tool was great for these kinds of things.

the reader most of our subscribers use (google) doesn't even handle the basic ATOM spec correctly, so i don't think it makes sense to hack around with custom ATOM feeds :)

I think we are talking the same thing, but at slightly different levels. As far as possible we have tried to stick to well accepted standards to make it easier for external parties to fetch and reuse the information. ATOM is one such standard, and it is an XML representation. We can choose to define our own XML representation, but then would have to go through the painful exercise of documenting what that means. Piggy backing of an existing standard will make it easier for you to understand the information being returned.

Second, ATOM allows for proprietary extensions. This is not considered a hack, but as part of the spec itself. Look at it this way, as long as we return you the needed information in XML, we will have to define a schema. Going with a standard schema (ATOM, RSS, etc.) will make it easier as you can use standard tools also.

My question above was related to asking if the namespace value is okay with PLoS and we have to do that regardless of the schema we choose.

ah okay. my point is that we must make sure that feed readers are able to grab a version of the feed that is bland and normal, without any extensions.

in comment 12 amit says:

Please note: it is very possible that this will cause some NON-CONFORMING READERS TO BREAK.

that's not okay. we need to have a way to grab a feed with the extra info, or to grab a feed without the extra info. the default should probably be the vanilla atom feed.

as for the naming, IMO since other users of the JPS will probably want additional information in their feeds as well, i don't think it makes sense to use "plos" as the namespace.

we should use jps or pub or topaz or some other namespace that is related to the project and doesn't reference a specific publisher. i think this should be a general rule and that all existing references to plos (in config files, as the name of services, etc.) should be removed.

since most/all of what we want to put in the article feed is part of the NLM DTD, is there anyway we can leverage their namespace?

Replying to russ:

since most/all of what we want to put in the article feed is part of the NLM DTD, is there anyway we can leverage their namespace?

That would a fine idea, except for the minor detail that NLM has no namespace.

(In [3296]) fixes #332 Add volume and issue number to extended ATOM feed

Note that you must specify the extended feed to get the issue and volume. That is, the cgi parameters should include extended=true.

The namespace for this extension is as indicated in #332 and is configurable in plosone.xml (see diffs associated with this checkin).

For example, with article 440, the following will be added to its entry:

    <plos:volume xmlns:plos="http://www.plos.org/atom/ns#plos">2</plos:volume>
    <plos:issue xmlns:plos="http://www.plos.org/atom/ns#plos">5</plos:issue>

This same mechanism can probably be used for all ATOM extensions. And to clarify what that is (given the rome api intentionally under-documents this in an attempt to prevent people from arbitrarily extending ATOM), the interface is as follows:

com.sun.syndication.feed.atom.Entry.setForeignMarkup(List<org.jdom.Element>);

See jdom api - specifically javadocs for Element. I'm fairly certain these things can be nested, but haven't tried yet.

Milestone 0.8 deleted