Subject: [rfc-i] Making the XML available

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2019 20:36:43 +0000

Hiya.   

The request is if the IETF could also make the final (post Auth48) XML for RFCs available?

The motivation is twofold:

To better support extracting content from RFCs.
current approach is to extract content (i.e. source code inclusions, such as YANG modules) from the plain-text, but this is not ideal and, not for lack of trying, does not result in perfect extractions (indents, outdents, extra lines, etc.).
To better support kick-starting a "biz" draft.
current approach is for authors to use the last posted revision of the draft, that which the IESG approved, but this version does not include any changes made by the copy editors.

It is understood that, today, the XML is used to generate the `nroff` format, and that final adjustments are made there.  It is assumed that the adjustments being made there are minor (e.g., pagination, flow, etc.) as, from experience, XML is used throughout the Auth48 process.

The request is to make this last XML version available.  

Since this XML is not the final version, there may be hesitation to publish it as another official "output" format.   To address this inconsistency, could language surrounding the link (e.g., a click-thru popup) be used to disclose it?

Alternatively, maybe no link is required, so long as it's well-known how to construct the URL to access it.  For example:

Given that:
Text     ----> https://tools.ietf.org/rfc/rfcXXXX.txt
PDFs   ----> https://tools.ietf.org/pdf/rfcXXXX.pdf
HTML  ----> https://tools.ietf.org/html/rfcXXXX

So, maybe:
XML    -----> https://tools.ietf.org/xml/rfcXXXX.xml
or        -----> https://tools.ietf.org/xml/rfcXXXX.xml

If only a well-known URL were made available, extraction-tools and bis-authors (per 1 and 2 above) would have what they need, without exposing the XML to the general public.

PS: I'm unsure if this is the best place to ask this question, so please bounce this message to another list if needed.

Thanks,
Kent

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Mar 2019 15:39:52 -0500

We are in the process of shifting to make the XML
1) The normative form
2) used to generate all other forms
3) Available directly

As such, why would we mess with trying to adjust / improve the current 
process when we hope to get away from it ASAP.

Yours,
Joel

On 3/5/19 3:36 PM, Kent Watsen wrote:
>  1. To better support extracting content from RFCs.
>       * current approach is to extract content (i.e. source code
>         inclusions, such as YANG modules) from the plain-text, but this
>         is not ideal and, not for lack of trying, does not result in
>         perfect extractions (indents, outdents, extra lines, etc.).
>  2. To better support kick-starting a "biz" draft.
>       * current approach is for authors to use the last posted revision
>         of the draft, that which the IESG approved, but this version
>         does not include any changes made by the copy editors.
> 
> 
> It is understood that, today, the XML is used to generate the `nroff` 
> format, and that final adjustments are made there.  It is assumed that 
> the adjustments being made there are minor (e.g., pagination, flow, 
> etc.) as, from experience, XML is used throughout the Auth48 process.
> 
> Since this XML is not the final version, there may be hesitation to 
> publish it as another official "output" format.   To address this 
> inconsistency, could language surrounding the link (e.g., a click-thru 
> popup) be used to disclose it?
> 
> Alternatively, maybe no link is required, so long as it's well-known how 
> to construct the URL to access it.  For example:
> 
> Given that:
> 
>   * Text     ----> https://tools.ietf.org/rfc/rfcXXXX.txt
>   * PDFs   ----> https://tools.ietf.org/pdf/rfcXXXX.pdf
>   * HTML  ----> https://tools.ietf.org/html/rfcXXXX
> 
> 
> So, maybe:
> 
>   * XML    -----> https://tools.ietf.org/xml/rfcXXXX.xml
>   * or        -----> https://tools.ietf.org/xml/rfcXXXX.xml
> 
> 
> If only a well-known URL were made available, extraction-tools and 
> bis-authors (per 1 and 2 above) would have what they need, without 
> exposing the XML to the general public.
> 
> 
> PS: I'm unsure if this is the best place to ask this question, so please 
> bounce this message to another list if needed.
> 
> Thanks,
> Kent
> 
> 
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2019 20:50:46 +0000

Hi Joel,

Yes, (1) and (2) are from RFC 7990, but I've seen nothing yet regarding (3).

Of course, if (3) is in motion already (e.g., as part of the v3 rollout), then 
this is just what I'm asking for.   Is this the case?

Kent

> On Mar 5, 2019, at 3:39 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> As such, why would we mess with trying to adjust / improve the current process when we hope to get away from it ASAP.
> 
> Yours,
> Joel
>

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 5 Mar 2019 16:00:16 -0500

Hi all,

I would add one more thing, with regards to the current XML files. XML files, where we have them today (which is not for everything) are not necessarily indicative of the final text. Changes may have been made in nroff prior to publication. Rather than potentially distribute incorrect material, we make it available per RFC upon request, which gives us an opportunity to make sure the recipient understands they may not be getting the final content of the RFC.

This will change, as Joel noted, in the v3 format world, but that won’t reflect back to any RFCs published before we go live with v3.

-Heather

> On Mar 5, 2019, at 15:39, Joel M. Halpern <[email-masked]> wrote:
>

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 5 Mar 2019 16:01:26 -0500

And, in response to this one, having the XML for all v3 (and beyond) RFCs is definitely in progress. 

-Heather

Sent from my iPad
> On Mar 5, 2019, at 15:50, Kent Watsen <[email-masked]> wrote:
> 
> Hi Joel,
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2019 21:21:38 +0000

Perfect, problem solved!

Kent

> On Mar 5, 2019, at 4:01 PM, Heather Flanagan <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 6 Mar 2019 06:09:19 +0100

> This will change, as Joel noted, in the v3 format world, but that won’t reflect back to any RFCs published before we go live with v3.

FWIW, the process of checking whether the XML actually *is* accurate can 
be fully automated...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Mar 2019 06:45:04 +0100

On Mar 6, 2019, at 06:09, Julian Reschke <[email-masked]> wrote:
> 
> FWIW, the process of checking whether the XML actually *is* accurate can be fully automated...

Well, some of the nroff phase changes are pagination only.
Is the XML (that doesn’t have the pagination tweaks) accurate then or not?
For continuing on a bis document, it certainly is.

(There is also the matter of <?rfc include=“…”?> targets changing, as it did with the introduction of DOIs.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 6 Mar 2019 06:52:07 +0100

> For continuing on a bis document, it certainly is.

Yes.

> (There is also the matter of <?rfc include=“…”?> targets changing, as it did with the introduction of DOIs.)

That's why having external dependencies in the final XML is a bad idea. 
FWIW, this special-case could easily be handled as well.

Best regards, Julian

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 5 Mar 2019 17:05:59 -0500

As far as I know, (3) (Making the XML as avaiable as any other form) is 
indeed the plan.

Yours,
joel