Re: [niso-sts] How to reference sections from another standard

Subject: Re: [niso-sts] How to reference sections from another standard
From: "Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx" <niso-sts-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 11 Apr 2018 19:01:48 -0000
Hi Doro,

In ISO STS, such a link would be encoded as <sts sts-id="{URN}">, where {URN} is a RFC 5141 URN. Example:

<std std-id="iso:std:iso:3745:ed-3:en:clause:A" type="dated"><std-ref>ISOB 3745:2012</std-ref>, AnnexB A</std>

See for instructions how to form URNs for these deep links.

Unfortunately, RFC 5141 is only defined for certain originators (the part after the second colon), namely "iso", "iso-iec", "iso-cie", "iso-astm", "iso-ieee", "iec".

Although you can, at least for internal use, extend it to allow an originator string that identifies other organizations, this flies in the face of the bUb in URN since it is not guaranteed that any two users of these privatized schemes will use the same identifier for the same organization.

In addition, many organizations use their own internal document identifiers for which there is no place in these URNs anyway.

Other users might want to use DOIs for identifying published standards, in order to be able to utilize this established permanent linking facility.

NISO STS addresses this request for multiple links by allowing multiple std-ids on the std element, grouped in an std-id-group (

However, NISO STS does not assume a particular linking scheme in these identifiers. The suggestions in are 'doi', 'urn', and 'internal-pub-id'.

DIN/Beuth are using their established internal document identifiers for linking. Example:

<std><std-id std-id-link-type="internal-pub-id" std-id-type="dated">d1ca7c3f#sub-a</std-id><std-ref>ISO 3745:2012</std-ref>, Annex A</std>

It is up to the rendering system to create a proper, user-actionable link then (for example, an HTML link that points to Beuthbs online platform).

In principle, they could have enhanced this link by DOIs, like this:

<std-id std-id-link-type="doi" std-id-type="dated"></std-id>
<std-id std-id-link-type="internal-pub-id" std-id-type="dated">
</std-id-group><std-ref>ISO 3745:2012</std-ref>, Annex A</std>

There are two issues with this. One is related to DOIs, the other is related to redundancy.

In the example above, the DOI is augmented by a fragment identifier. This may or may not be forwarded from the DOI resolver to the publisher, and since fragment identifiers are resolved by the client (browser), it is not guaranteed that the publisherbs Web server will serve the document in its entirety so that your client can navigate to #sub-a, nor is it guaranteed that the rendered document uses the same ID scheme.
Of course this is hypothetical: If a standards publisher creates DOIs with fragment identifiers, they should make sure to take the user to the deep link if such a fragment identfier is contained in the DOI.
And I think crossrefbs resolver will append the fragment identifier to the resolved publisher URL, so this should work in practice.
A while ago, Bruce Rosenblum checked with someone from Crossref whether theybd recommend such a fragment identifier approach, and they did not.
The alternative is to register distinct DOIs that will resolve to a URL that directly points to document fragments on the publisherbs platform. But this is prohibitively costly. And still, youbd have to operate a local cache of all deep-linking DOIs because you probably donbt want to query the central CrossRef server in order to resolve them, or you donbt want to send the users through CrossRef for following a link that could also point directly from your platform to your platform.

The other issue is redundancy. Quite often, a link to a certain entity occurs multiple times in a document. You donbt want to supply IDs for all the different naming schemes at every single link location. So it is probably wise to just use identifiers in a single internal scheme.
In order to decrease this redundancy, Beuth has maintained, in the document metadata, a centralized list of all references with their internal IDs and with their XML formal public identifiers. From within the document, they just referred to that central, per-document multi-ID storage with an xref-like mechanism. This is admittedly an additional level if indirection, but it avoids dangerous redundancy where errors may be introduced by copying and pasting during document editing.

So Ibd recommend to avoid this redundancy in NISO STS, too. DIN/Beuth are currently mimicking their old centralization approach by creating a ref-list in the document frontmatter and storing all the std-id-groups there, only referring to them from the text by something like <xref ref-type="bibr" rid="nla-nat-1">EN ISO 3745:2012</xref>.
The centralized ref-lists are stored like this, in a NISO STS compliant manner:
<notes notes-type="bibl" specific-use="centralized-citations">
<ref-list content-type="invisible-citation-list">
<ref id="nla-nat-1">
<std-id std-id-link-type="internal-pub-id" std-id-type="dated">d53f90ba</std-id>
<std-id std-id-link-type="fpi" std-id-type="dated">+//ISO 9070/RA::A00007::GE::DIN German Institute for Standardization::Regulations//DOCUMENT EN ISO 3745:2012-03-00//DE</std-id>
<ref id="nla-nat-2">

My recommendation is to roll your own (publisher-internal) ID scheme that you use for deep links. This can be URLs like the URLs, but with your own host name in it. One prerequisite of this ID scheme is that it should be easy to recognize the ID for the whole document when you see a deep link ID. Another recommendation is that fragment identifiers in this private ID scheme should correspond to XML IDs in the documents.
Finally, when you have adoptions like DIN EN ISO 3745, you should assign a distinct document ID to each shell (ISO, CEN, DIN) / language (de, en, b&) combination. For example, d1ca7c3f#sub-a points to Annex A in the compound German-language DIN EN ISO document while d53f90ba#sub-a points to Annex A either in the compound German DIN EN ISO document or in the German EN ISO document, and d1d1d9e3#sub-a points to Annex A either in DIN EN ISO 3745 or in the German translations of EN ISO 3745 or ISO 3745.
In these examples, 'd1ca7c3f' is the doc ID of the German-language edition of DIN EN ISO 3745:2012, 'd53f90ba' corresponds to EN ISO 3745:2012 (in German), and 'd1d1d9e3' is for ISO 3745:2012 (German translation).
You donbt need to use cryptic IDs like that, you can create your own URLs with fragment identifiers, or languages encoded by name/value pairs in the query strings.
You only need to run your own resolver when rendering the standards to HTML or PDF, or when exporting the XML for someone else with their own naming scheme. The resolver should be able to collate the internal IDs with the ISO URNs of adopted standards so youbre on the same page with someone who has also created a nationalized version of a certain ISO standard. So both of you can tell: This is the German-language version of the same EN adoption of iso:std:iso:3745:ed-3 that the Finnish guy refers to in their naming scheme.
Such a resolver is typically implemented in Java or XQuery, and it will use some kind of database.

Btw, donbt use ext-link within std. std is a domain-specific replacement for ext-link.


On 11/04/2018 12:07, DorothC)e Stadler doro@xxxxxxxxxxx wrote:
I am wondering how to correctly reference a specific section from another standard. Our national standards have IDs on all sections and elements.
Say, for example, I want to make a reference to Section 5 in Standard ABC:2017 from my standard, how to best to this?

Should I put the standard reference inside <std> and then use <ext-link> to hold the reference to the section?
<std>Standard ABC <ext-link xlink:href=bSection_IDb>Section 5--</ext-link></std>

Is there a way to identify that the <ext-link> is a reference to an element inside another standard (as opposed to other <ext-link> elements in the standard that would point to URLs for example)?

Or is there a better way of doing this?
Is it OK to put just the ID of the section inside the @xlink:href?

Thanks for your help in this!
Greetings from Berlin,
DorothC)e Stadler

Rathenower Str. 38
10559 Berlin
Tel: +49 1525 840 85 93
doro@xxxxxxxxxxx <mailto:doro@xxxxxxxxxxx>

You are subscribed as gerrit.imsieke@xxxxxxxxx to NISO STS Discussion by Mulberry Technologies, Inc. <>
EasyUnsubscribe <-sts-list/225679> (by email <>)

-- Gerrit Imsieke GeschC$ftsfC<hrer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@xxxxxxxxx,

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

GeschC$ftsfC<hrer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt

Current Thread