search

metanorma / metanorma-ietf

Metanorma processor for IETF documents
BSD 2-Clause "Simplified" License
6 stars 5 forks source link

`:sort-refs:` document attribute should not crash xml2rfc when not given `true` or `false` as value #194

Closed ronaldtse closed 10 months ago

ronaldtse commented 1 year ago

From https://github.com/cisba/i-d_dlts/pull/1#issuecomment-1782171074

From @opoudjis :

I will review the RFC XML v3 spec and see what discussion there has been, if any, about sorting references, and what has currently been implemented as the sort order.

https://github.com/metanorma/metanorma-ietf/issues/192

But I have had a backlog of 100 tickets for the past 3 years, and one of the major reasons for that is making things more flexible for users. And you will have noticed how unresponsive I have been for the past three weeks: I have been knee-deep in ISO 10303, which has an end-of-year deadline, and is extremely difficult to keep straight.

So the answer to that question may be "no", depending on how it is currently implemented, and what the existing practice is.

One thing that may short circuit this entire discussion: try

:sort-refs:

in the document header attributes. That passes on the sort-refs directive to xml2rfc, and if that directive is working, it may sort the references the way IETF wants to see them sorted.

According to: https://www.metanorma.org/author/ietf/ref/document-attributes/

Screenshot 2023-10-31 at 1 36 00 PM

But specifying this attribute leads to this error:

draft-intesigroup-dlts.rfc.xml(9): Error: Invalid attribute sortRefs for element rfc, at /rfc
draft-intesigroup-dlts.rfc.xml(9): Error: Invalid document before running preptool.
opoudjis commented 1 year ago

Cannot replicate on an empty document, I don't get such an error at all.

opoudjis commented 1 year ago

I'm compiling with xml2rfc 3.18.2, and that schema allows sortRefs explicitly on its root: https://ietf-tools.github.io/xml2rfc/#name-rfc

Running xml2rfc on the following as a.rfc.xml:

<?xml version="1.0" encoding="UTF-8"?>
<?rfc comments="yes"?>
<?rfc notedraftinprogress="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-camelot-holy-grenade-01" category="info" ipr="trust200902" sortRefs="true" tocInclude="true" submissionType="editorial" xml:lang="en" version="3" >
  <front>
    <title abbrev="Hand Grenade of Antioch">The Holy Hand Grenade of Antioch</title>
    <seriesInfo value="draft-camelot-holy-grenade-01" status="Informational" stream="editorial" name="Internet-Draft" asciiName="Internet-Draft"></seriesInfo>
    <seriesInfo name="" value="" status="informational"></seriesInfo>
    <author fullname="Arthur son of Uther Pendragon">
      <organization>Slate Rock and Gravel Company</organization>
      <address>
        <postal>
          <postalLine ascii="Palace">Palace</postalLine>
          <postalLine ascii="Camel Lot 1">Camel Lot 1</postalLine>
        </postal>
        <email>arthur.pendragon@ribose.com</email>
        <uri></uri>
      </address>
    </author>
    <area>General</area>
    <area>Operations and Management</area>
  </front>
  <middle>
    <section anchor="_scope"><name>Scope</name>

<t anchor="_a0704f72-31bc-9bed-1ed3-962b00267fe2">nothing</t>
</section>
  </middle>
  <back></back>
</rfc>

returns valid XML RFC output:

Network Working Group                              A. S. O. U. Pendragon
Internet-Draft                             Slate Rock and Gravel Company
Intended status: Informational                           6 November 2023
Expires: 9 May 2024

                    The Holy Hand Grenade of Antioch
                     draft-camelot-holy-grenade-01

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 May 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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.

Table of Contents

   1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   1

1.  Scope

   nothing

Author's Address

Pendragon                  Expires 9 May 2024                   [Page 1]
^L
Internet-Draft           Hand Grenade of Antioch           November 2023

   Arthur son of Uther Pendragon
   Slate Rock and Gravel Company
   Palace
   Camel Lot 1
   Email: arthur.pendragon@ribose.com

@ronaldtse kindly parse the following on your end and tell me what you get, because this bug report makes no sense to me.

Archive.zip

I'll add that I am not getting the current PR on https://github.com/metanorma/i-d_dlts/tree/update-to-latest-mn to compile successfully. I'm not confident we have the same environment.

ronaldtse commented 1 year ago

sort-refs

There is a not-so-subtle difference in the attribute setting between ours:

Me:

:sort-refs:

=>

RFC XML: Line 000009:179 value of attribute "sortRefs" is invalid; must be equal to "false" or "true"
...

You:

:sort-refs: true

I'd imagine that maybe we should support the :sort-refs: declaration itself without needing to state true because that's the typical AsciiDoc practice.

e.g. 

:local-cache-only:
:data-uri-image:

Not building

Actually I was using an older xml2rfc version. Now at 3.18.2, the document doesn't build, and it is a Metanorma IETF problem.

The real error is:

RFC XML: <relref target="RFC6962" section="2.1"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC5652" section="1.3"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC5652" section="5.3"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC5652" section="10.2.4"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC3161" section="2.4.2"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC5652" section="5.3"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC3161" section="2.4.2"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC4210" section="5.2.3"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC3161" section="2.4"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC5280" section="4.2"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC3161" section="2.4.2"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC4210" section="5.2.3"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
RFC XML: <relref target="RFC3161" section="4"/> must use a relative attribute, since it does not point to a RFC or Internet-Draft reference
Cannot continue processing

There is some issue with bibliography processing that xml2rfc fails to recognize that the Metanorma references to RFCs are not identified as "RFC".

These are references that have a locality, which used to work before (with the older xml2rfc):

... <<RFC5652,section=10.2.4>>

So Metanorma-IETF needs to fix citations for RFCs (and possibly Internet-Drafts) with a locality is given.

opoudjis commented 1 year ago

I'd imagine that maybe we should support the :sort-refs: declaration itself without needing to state true because that's the typical AsciiDoc practice.

That's nice. Not a priority.

There is some issue with bibliography processing that xml2rfc fails to recognize that the Metanorma references to RFCs are not identified as "RFC".

Moved to https://github.com/metanorma/metanorma-ietf/issues/196