fix: Use bib.ietf.org for citations

[kesara]

#799 was incomplete, this change fixes the issue.
Fixes #792

[kesara]

Tests are failing because reference.DOI.10.1145/2975159 doesn't have date element under front element.
This violates rfc2629.dtd.

[cabo]

Is the DTD still relevant? Sent from mobile, sorry for terse

…

On 6. Jul 2022, at 03:46, Kesara Rathnayake ***@***.***> wrote:  Tests are failing because reference.DOI.10.1145/2975159 doesn't have date element under front element. This violates rfc2629.dtd. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[ronaldtse]

The DTD does not reflect the actual schema being used?

From https://authors.ietf.org/rfcxml-vocabulary

it says the “date” attribute is optional:

front =
  element front {
    attribute xml:base { text }?,
    attribute xml:lang { text }?,
    title,
    seriesInfo*,
    author+,
    date?,
    area*,
    workgroup*,
    keyword*,
    abstract?,
    note*,
    boilerplate?,
    toc?
  }

If xml2rfc wants to make it mandatory, the spec needs to be updated.

CC: @strogonoff

[cabo]

@ronaldtse: The reference file doesn't just have to be valid according to the grammar, it also has to be a usable reference. https://bib.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml fails that in a way that is almost comical.

[kesara]

The DTD does not reflect the actual schema being used?

From https://authors.ietf.org/rfcxml-vocabulary

it says the “date” attribute is optional:

front =
  element front {
    attribute xml:base { text }?,
    attribute xml:lang { text }?,
    title,
    seriesInfo*,
    author+,
    date?,
    area*,
    workgroup*,
    keyword*,
    abstract?,
    note*,
    boilerplate?,
    toc?
  }

If xml2rfc wants to make it mandatory, the spec needs to be updated.

CC: @strogonoff

This is true for xml2rfc v3.
But the for the xml2rfc v2, date is mandetory.

[ronaldtse]

@cabo I'm perplexed about this comment:

https://bib.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml fails that in a way that is almost comical.

Are you commenting about the format of the anchor reference being different from the old one? Am I missing a joke here?

But the for the xml2rfc v2, date is mandetory.

@kesara thanks for the clarification. From what I understand, the BibXML service produces BibXML that targets xml2rfc v3 compliance.

[ronaldtse]

If the goal is to have full compatibility with v2 XML schema, and that the data be given in v2 XML, I suggest that these tools do not be migrated to use bib.ietf.org at all.

We can separately create a duplicate static site for xml2rfc.tools.ietf.org/public/rfc/... enable the archival paths that currently exist, and this archive site will not get updates. That would solve backwards compatibility fully. Given that the IETF community has already moved to v3, and v2 is deprecated, anything that is still in v2 should really either get updated or get dropped, so updates should not be important for them.

@rjsparks any thoughts here?

[strogonoff]

But the for the xml2rfc v2, date is mandetory.

I think the objective was somewhat fuzzy in that we are trying to comply with xml2rfc v3, but we also try to be compatible with the old data. Missing <date> is an example of a dilemma.

According to https://github.com/ietf-ribose/bibxml-service/issues/228#issuecomment-1198141887, it seems like we can omit <date> in cases where suitable date information is not available.

The only alternative is to supply fake date information…

[strogonoff]

Are you commenting about the format of the anchor reference being different from the old one?

@ronaldtse I suppose @cabo hints at DOI anchor being different. This is something that was raised before and had been fixed (the fix hadn’t made it to production yet, but can be seen in action on staging instance).

[rjsparks]

If the goal is to have full compatibility with v2 XML schema, and that the data be given in v2 XML, I suggest that these tools do not be migrated to use bib.ietf.org at all.

We can separately create a duplicate static site for xml2rfc.tools.ietf.org/public/rfc/... enable the archival paths that currently exist, and this archive site will not get updates. That would solve backwards compatibility fully. Given that the IETF community has already moved to v3, and v2 is deprecated, anything that is still in v2 should really either get updated or get dropped, so updates should not be important for them.

@rjsparks any thoughts here?

That is absolutely not acceptable. The RFP was quite clear that this service would continue to make bibxml available at the existing URLs.

This conversation is now hitting alarming levels, and it may be that we cannot use this new service as implemented at all.

The characterization that this is there only for v2 is incorrect. The legacy v2 paths and things that rely on v2v3 will be heavy users, but those things, like kramdown rfc, which has a huge amount of active use will continue to need to be able to reference new documents.

You are trying to shed a requirement that cannot be shed.

Because of illnesses and travel it may be week after next before we can be on a call, but a call is essential at this point. We will work to set it up by direct email.