Content Compare NISO-STS API endpoints
REST API
The REST API is available at https://saas.deltaxml.com/api/content-compare/v1/NISOSTS
Content Compare NISO-STS is a very simple REST API with two endpoints: /compare
and /authorise
.
Endpoint | Method | Description | Documentation |
---|---|---|---|
| POST | comparison of two XML files | |
| GET | refresh access token |
POST /compare
Comparisons are posted using multipart/form-data
to
https://saas.deltaxml.com/api/content-compare/NISOSTS/v1/compare
Parameter | Description |
---|---|
REQUIRED | Input A to the comparison. We only display the changes in content from this version. See information below on how to send input files. |
REQUIRED | Input B to the comparison. We retain the structure of this input in the result file. See information below on how to send input files. |
| Use |
Authorisation
To make a comparison you will need to set the Authorization header to use your id as a Bearer token, for example:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
How to Send Input Files
Files can be sent in two ways: URLs, or as raw XML.
URL inputs
For secure URLs set the Content-Type
of the inputA
/inputB
to text/plain
.
Here is an example:
...
----form-boundary-id
Content-Disposition: form-data; name="inputA"
Content-Type: text/plain
https://www.example.com/NISO-STS/inputA.xml
----form-boundary-id
...
Raw XML inputs
To send raw XML you can send either a raw XML string, or attach an XML file.
Set the Content-Type
of the inputA
/inputB
part to application/xml
or text/xml
.
Here is an example:
...
----form-boundary-id
Content-Disposition: form-data; name="inputA"
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<content xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.NISO-STS.org/NISO-STS_5-0/xml_schema_flat/descript.xsd">
<description>
<levelledPara>...etc...
----form-boundary-id
...
Responses
200 Successful comparison returns the comparison result.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE standard SYSTEM "NISO-STS-extended-1-mathml2.dtd">
<standard dtd-version="1.0" xml:lang="en">
<front>
<std-meta>
<title-wrap>
<full>GeoJSON Text Sequences</full>
</title-wrap>
<std-ident>
<doc-type>Request for Comments</doc-type>
<doc-number>8142</doc-number>
<issn>2070-1721</issn>
</std-ident>
<std-org>
<std-org-name>Internet Engineering Task Force</std-org-name>
<std-org-abbrev>IETF</std-org-abbrev>
</std-org>
<release-date date-type="published">April 2017</release-date>
<permissions>
<copyright-statement>Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.</copyright-statement>
<license>
<license-p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</license-p>
</license>
</permissions>
<abstract>
<title>Abstract</title>
<p>
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>All rights reserved under International and Pan-American Copyright Conventions. For noncommercial purposes only, this publication may be reproduced or transmitted in any form or by any means without prior permission in writing from the publisher, provided it is reproduced accurately, the source of the material is identified, and the NISO copyright status is acknowledged. All inquiries regarding translations into other languages or commercial reproduction or distribution should be addressed to: NISO, 3600 Clipper Mill Road, Suite 302, Baltimore, MD 21211-1948.
<?oxy_insert_end?>
</p>
<p>This document describes the GeoJSON text sequence format and "application/geo+json-seq" media type. This format is based on JavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.</p>
</abstract>
<custom-meta-group>
<custom-meta>
<meta-name>Category</meta-name>
<meta-value>Standards Track</meta-value>
</custom-meta>
<custom-meta>
<meta-name>author</meta-name>
<meta-value>S. Gillies</meta-value>
</custom-meta>
<custom-meta>
<meta-name>auth-org</meta-name>
<meta-value>Mapbox</meta-value>
</custom-meta>
</custom-meta-group>
</std-meta>
<sec>
<title>Status of This Memo</title>
<p>This is an Internet Standards Track document.</p>
<p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.</p>
<p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8142.</p>
</sec>
</front>
<body>
<sec id="s1">
<label>1.</label>
<title>Introduction</title>
<p>Arbitrarily large sequences of values pose a problem for JavaScript Object Notation (JSON) [RFC7159] that is well explained in the motivation for JSON text sequences [RFC7464]. The GeoJSON format [RFC7946] faces the same kind of problem. Geographic datasets often run to the tens of thousands or millions of features. The problem is often amplified by the presence of large arrays of coordinates for each of the features.</p>
<p>
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>These standards may be revised or withdrawn at any time. For current information on the status of this standard contact the NISO office or visit the NISO website at:
<?oxy_insert_end?>
<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" ext-link-type="uri" xlink:href="https://www.niso.org">
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>https://www.niso.org
<?oxy_insert_end?>
</ext-link>
</p>
<p>This document describes a specialization of JSON text sequences. A GeoJSON text sequence is a document of arbitrarily large size containing one or more GeoJSON objects (e.g., multiple GeoJSON texts that can be produced and parsed incrementally) and not just a single GeoJSON FeatureCollection, Feature, or Geometry.</p>
<sec id="s1.1">
<label>1.1.</label>
<title>Requirements Language</title>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].</p>
</sec>
</sec>
<sec id="s2">
<label>2.</label>
<title>GeoJSON Text Sequence Format</title>
<p>Defined in prose similar to the description of the JSON text sequence in [RFC7464], a GeoJSON text sequence is any number of GeoJSON [RFC7946] texts, each encoded in UTF-8 [RFC3629], preceded by one ASCII [RFC20] record separator (RS) character, and followed by a line feed (LF).</p>
<p>The GeoJSON text sequence format conforms to all the rules of [RFC7464] and adds the following constraint: each JSON text MUST contain a single GeoJSON object as defined in [RFC7946].</p>
<p>Heterogeneous sequences containing a mix of GeoJSON Geometry, Feature, and FeatureCollection objects are permitted. How producers and parsers of GeoJSON text sequences communicate rules for allowed GeoJSON types in exchanged sequences is not specified in this document.</p>
</sec>
<sec id="s3">
<label>3.</label>
<title>Security Considerations</title>
<p>GeoJSON text sequences have no security considerations beyond those of JSON text sequences [RFC7464] and the GeoJSON format [RFC7946].</p>
</sec>
<sec id="s4">
<label>4.</label>
<title>Interoperability Considerations</title>
<p>The advantage of using ASCII character RS "0x1e" to denote a text is that sequence producers and parsers need not enforce a canonical form of GeoJSON. Any valid GeoJSON, pretty-printed or compact, can be used in a GeoJSON text sequence.</p>
<p>A variety of parsers designed for newline-delimited sequences of compact JSON text are deployed on the internet today. While there is no canonical form for JSON texts, and pretty-printed and compact forms are equally valid, GeoJSON text sequences containing compact GeoJSON texts with no internal newlines are more interoperable with existing non-standardized parsers.</p>
<p>In a distributed system where order and exactly-once delivery of messages are difficult to achieve, GeoJSON text sequences that do not rely on order of texts for extra semantics are more interoperable than those that do.</p>
<p>
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>ISO STS was based on version 0.4 (Publishing) of the Journal Article Tag Suite (JATS), now known in its updated form as ANSI/NISO Z39.96. The current NISO STS standard is based on ANSI/NISO Z39.96-2015, which is based on the National Library of Medicine (NLM) Journal Archiving and Interchange Tag Suite, created by The National Center for Biotechnology Information (NCBI):
<?oxy_insert_end?>
<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" ext-link-type="uri" xlink:href="https://www.ncbi.nlm.nih.gov">
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>https://www.ncbi.nlm.nih.gov
<?oxy_insert_end?>
</ext-link>
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?> of the National Library of Medicine (NLM):
<?oxy_insert_end?>
<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" ext-link-type="uri" xlink:href="https://www.nlm.nih.gov">
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>https://www.nlm.nih.gov
<?oxy_insert_end?>
</ext-link>
<?oxy_insert_start author="deltaxml" timestamp="20220809T142518+0100"?>. The NLM Tag Suite was developed as an update of a Document Type Definition (DTD) used by the NCBI/NLM PubMed Central project to archive life science journals from a variety of sources. Input and support from Harvard University Libraries, as well as support from The Andrew W. Mellon Foundation and collaboration with Inera, Inc. and Mulberry Technologies, Inc., allowed the scope of that project to be broadened and resulted in the NLM Journal Archiving and Interchange Tag Suite.
<?oxy_insert_end?>
</p>
</sec>
<sec id="s5">
<label>5.</label>
<title>IANA Considerations</title>
<p>The MIME media type for GeoJSON text sequences is "application/ geo+json-seq" (which uses the suffix established in [RFC8091]). IANA has registered it in the "Media Types" registry <https://www.iana.org/assignments/media-types/>.</p>
<def-list>
<def-item>
<term>Type name:</term>
<def>
<p>application</p>
</def>
</def-item>
<def-item>
<term>Subtype name:</term>
<def>
<p>geo+json-seq</p>
</def>
</def-item>
<def-item>
<term>Required parameters:</term>
<def>
<p>n/a</p>
</def>
</def-item>
<def-item>
<term>Optional parameters:</term>
<def>
<p>n/a</p>
</def>
</def-item>
<def-item>
<term>Encoding considerations:</term>
<def>
<p>binary</p>
</def>
</def-item>
<def-item>
<term>Security considerations:</term>
<def>
<p>See Section 3 of RFC 8142</p>
</def>
</def-item>
<def-item>
<term>Interoperability considerations:</term>
<def>
<p>See Section 4 of RFC 8142</p>
</def>
</def-item>
<def-item>
<term>Published specification:</term>
<def>
<p>RFC 8142</p>
</def>
</def-item>
<def-item>
<term>Applications that use this media type:</term>
<def>
<p>Geographic information systems (GIS)</p>
</def>
</def-item>
<def-item>
<term>Additional information:</term>
<def>
<p>
<def-list>
<def-item>
<term>Deprecated alias names for this type:</term>
<def>
<p>n/a</p>
</def>
</def-item>
<def-item>
<term>Magic number(s):</term>
<def>
<p>n/a</p>
</def>
</def-item>
<def-item>
<term>File extension(s):</term>
<def>
<p>n/a</p>
</def>
</def-item>
<def-item>
<term>Macintosh file type code(s):</term>
<def>
<p>n/a</p>
</def>
</def-item>
</def-list>
</p>
</def>
</def-item>
<def-item>
<term>Person to contact for further information:</term>
<def>
<p>Sean Gillies (sean.gillies@gmail.com)</p>
</def>
</def-item>
<def-item>
<term>Intended usage:</term>
<def>
<p>COMMON</p>
</def>
</def-item>
<def-item>
<term>Restrictions on usage:</term>
<def>
<p>none</p>
</def>
</def-item>
<def-item>
<term>Author:</term>
<def>
<p>Sean Gillies (sean.gillies@gmail.com)</p>
</def>
</def-item>
<def-item>
<term>Change controller:</term>
<def>
<p>IETF</p>
</def>
</def-item>
</def-list>
</sec>
<sec id="s6">
<label>6.</label>
<title>References</title>
<sec id="s6.1">
<label>6.1.</label>
<title>Normative References</title>
<ref-list>
<ref id="nr1">
<label>[RFC20]</label>
<std>Cerf, V., "ASCII format for network interchange," STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.</std>
</ref>
<ref id="nr2">
<label>[RFC2119]</label>
<std>Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.</std>
</ref>
<ref id="nr3">
<label>[RFC3629]</label>
<std>Yergeau, F., "UTF-8, a transformation format of ISO 10646," STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.</std>
</ref>
<ref id="nr4">
<label>[RFC7159]</label>
<std>Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format," RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.</std>
</ref>
<ref id="nr5">
<label>[RFC7464]</label>
<std>Williams, N., "JavaScript Object Notation (JSON) Text Sequences," RFC 7464, DOI 10.17487/RFC7464, February 2015, <http://www.rfc-editor.org/info/rfc7464>.</std>
</ref>
<ref id="nr6">
<label>[RFC7946]</label>
<std>Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., and T. Schaub, "The GeoJSON Format," RFC 7946, DOI 10.17487/RFC7946, August 2016, <http://www.rfc-editor.org/info/rfc7946>.</std>
</ref>
</ref-list>
</sec>
<sec id="s6.2">
<label>6.2.</label>
<title>Informative References</title>
<ref-list>
<ref id="ir1">
<label>[RFC8091]</label>
<std>Wilde, E., "A Media Type Structured Syntax Suffix for JSON Text Sequences," RFC 8091, DOI 10.17487/RFC8091, February 2017, <http://www.rfc-editor.org/info/rfc8091>.</std>
</ref>
</ref-list>
</sec>
</sec>
</body>
<back>
<sec id="b1">
<title>Author's Address</title>
<address>
<addr-line>Sean Gillies</addr-line>
<addr-line>
<institution>Mapbox</institution>
</addr-line>
<email>sean.gillies@gmail.com</email>
<uri>http://sgillies.net</uri>
</address>
</sec>
</back>
</standard>
GET /authorise
Get updated token information by using your refresh
, id
, and expiry
information you downloaded earlier by passing them as query parameters to /authorise
, for example:
GET https://saas.deltaxml.com/api/content-compare/v1/NISO-STS/authorise?refresh=ABCDEF123&expiry=1648141119&id=id
The response will be in the same JSON format you received when you requested your token.
Errors
400 Bad Request. Check the error message for details of what may need to be changed when you re-attempt the comparison. If you continue to receive an error, please contact support using our Customer Support Portal and report the error details.
500 Server Error. If you encounter these, please contact support using our Customer Support Portal and report the error details.
Errors will be reported with a parent element of <error>
containing these child elements:
<errorMessage>
- description of the error<errorId>
- unique ID to track errors<errorCode>
- the HTTP Response code<timestamp>
- ISO 8601 timestamp
An example of an error:
<error>
<errorMessage>Parameter output-type value is invalid. Please choose from oxygen-tc or NISO-STS(default)</errorMessage>
<errorId>8d395670-2e56-490d-9c3b-f87ee0154f81</errorId>
<errorCode>400</errorCode>
<timestamp>2022-03-24T14:19:29.516+0000</timestamp>
</error>
Restrictions
Only NISO-STS content can be compared. Files will be rejected by the API if they do not conform and you will receive an error.
If you’re getting an error message blocking your NISO-STS content from being compared, please contact DeltaXML.
Usage Limit
Trial users get 100 comparisons / month.
Paid subscribers get 1000 comparisons / month. To request more, please contact DeltaXML.
To see your current usage, go to Subscription Manager in MyDelta and find the relevant deal. Under the “Quantity” column will be information on your current usage level.
Input Size Limit
There is an input size limit of 5 Mb for each input file for trial users.
Ready to Subscribe?
If you’re ready to subscribe to Content Compare NISO-STS, please contact DeltaXML.