search

metanorma / metanorma-ogc

Metanorma processor for OGC documents
https://www.metanorma.com
BSD 2-Clause "Simplified" License
2 stars 3 forks source link

(Urgent) IETF references should point to IETF official xml2rfc site XML #285

Closed ronaldtse closed 3 years ago

ronaldtse commented 3 years ago

From 20-010:

image

This is probably a bug in Relaton-IETF, ping @andrew2net .

andrew2net commented 3 years ago

@ronaldtse IetfBibliographicItem instance has 2 type of links xml and src. The src link points to https://www.rfc-editor.org/info/. The xml link points to a GH repo https://raw.githubusercontent.com/relaton/relaton-data-ietf/ because the repo contains copies of the RFC/XML files from https://xml2rfc.tools.ietf.org/public/rfc/ and these files don't contain links to the original XML publications. If we need xml links to point to the official xml2rfc site then it needs to change the format of the files saved to relaton-data-ietf to RelatonXML with adding original xml links to them. Does it make sense?

ronaldtse commented 3 years ago

Actually the original post is wrong. Here, we want to point to the actual source document (the RFC document), not the location of the bibitem of the document.

For RFC 2045, are you saying that src points to https://www.rfc-editor.org/rfc/rfc2045.txt?

andrew2net commented 3 years ago

For RFC 2045, are you saying that src points to https://www.rfc-editor.org/rfc/rfc2045.txt?

Yes, I'm

ronaldtse commented 3 years ago

@andrew2net then is this a Metanorma bug that it should reference src?

In any case, we should separate these two:

And we should only store Relaton formatted data in relaton-data-*.

andrew2net commented 3 years ago

For RFC 2045, are you saying that src points to https://www.rfc-editor.org/rfc/rfc2045.txt?

Oh.. my bad, it points to https://www.rfc-editor.org/info/rfc2045 not txt file

andrew2net commented 3 years ago

@andrew2net then is this a Metanorma bug that it should reference src?

Yes, Metanorma should select reference by type.

In any case, we should separate these two:

  • authoritative bibitem XML source (https://xml2rfc.tools.ietf.org/public/rfc/...)
  • fetched bibitem XML source (https://raw.githubusercontent.com/relaton/relaton-data-ietf/...)

And we should only store Relaton formatted data in relaton-data-*.

I've planned to move code from relaton-data-ietf to the relaton-ietf so I'll change the format to RelatonXML and make xml links point to original publications. Hope it isn't an urgent task, is it?

ronaldtse commented 3 years ago

For RFC 2045, are you saying that src points to https://www.rfc-editor.org/rfc/rfc2045.txt?

Oh.. my bad, it points to https://www.rfc-editor.org/info/rfc2045 not txt file

Oh, that's perfectly fine, no need to change that.

ronaldtse commented 3 years ago

Yes, Metanorma should select reference by type.

But how come other references, e.g. for OGC, are correct? Is Metanorma getting the src for OGC but getting xml from IETF?

I've planned to move code from relaton-data-ietf to the relaton-ietf so I'll change the format to RelatonXML and make xml links point to original publications. Hope it isn't an urgent task, is it?

Not super hurry but let's get that done by early next week.

andrew2net commented 3 years ago

But how come other references, e.g. for OGC, are correct? Is Metanorma getting the src for OGC but getting xml from IETF?

In the BibliographicItem model, references are an array. For OGC only one type (obp) of reference is available to parse. For IETF 2 types of reference are available. It seems Metenorma just takes the first reference from the array.

ronaldtse commented 3 years ago

Do we have documentation on which links are available in what flavors? Without documentation it is hard to use.

From @opoudjis :

that should be a <relation type="describedBy"><bibitem><uri>...</uri></bibitem></relation>

the bibitem record contains attributes of the book, not attributes of its metadata

Put the metadata URI into a relation, it does not belong as a uri in the bibitem.

only uris of the referent belong in there, and the bibliographic description uri is not a uri of the referent

We are in fact using uri[@type = citation] in collection processing, to force the hyperlinks between documents

If you differentiate the kinds of things a uri points to, the PROPER thing to do is to differentiate those things as relations, and attach the uris to them, rather than randomly make up different type of uri:

  1. link to doc
  2. link to particular format of doc

the particular format should properly be a related bibitem giving the format

link to authoritative bib item, link to other formats of the bib item, where this bib item is downloaded from : these as uris of the bibliographic description, that should be a separate related bibitem

This has come up before, and an unmanaged dump of uris in the same spot, with an unmanageable enum of types, is not the way to do it

andrew2net commented 3 years ago

Do we have documentation on which links are available in what flavors? Without documentation it is hard to use.

@ronaldtse we don't. I'll create a ticket for the issue.

andrew2net commented 3 years ago

@ronaldtse added documentation on the availability of link types.

ronaldtse commented 3 years ago

@andrew2net can you describe what those links are? In the IETF documentation it does not describe what those links mean at all:

https://github.com/relaton/relaton-ietf/commit/8c182898d63a41b6e8195ff6f2a55dc5a80efa9f#diff-1194561cbea346acb1bea37d81fdf5c70def982dcbb0c64eca2a96bc51941124

andrew2net commented 3 years ago

@ronaldtse done

opoudjis commented 3 years ago

I'm going to do a general preferencing of uri[@type = 'src'] if available, else the first available, in rendering references. This needs to be applicable across all relaton flavours.