Subject: [Tools-discuss] How often are bibxml3 files generated?

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Jan 2018 23:24:02 +0100

Background for the question: I just split a draft into two; submitted the spin-off (which references an old version of the original), and now am waiting for the bibxml3 file to turn up so I can push the reduced original (which references the spin-off) to github with an expectation that the CI will work.

Is there a reason this takes more than, say, a few minutes?

(Bonus: if someone figures out how to do mutual references without the help of the RFC editor, I’ll buy you a beer in London :-)						

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 28 Jan 2018 15:15:32 +0100

Hi Carsten,

The answer is: hourly, starting at 15 minutes past the hour.

On 2018-01-27 23:24, Carsten Bormann wrote:
> Background for the question: I just split a draft into two; submitted
> the spin-off (which references an old version of the original), and
> now am waiting for the bibxml3 file to turn up so I can push the
> reduced original (which references the spin-off) to github with an
> expectation that the CI will work.
> 

Simple answer: it's driven by cron, and iterates through all drafts
every time.  Replacing the old cronjob with on-the-fly generation in
the datatracker would change things completely.

> (Bonus: if someone figures out how to do mutual references without
> the help of the RFC editor, I’ll buy you a beer in London :-)

Could you say a bit more so I'm sure I understand the issue?

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jan 2018 16:44:27 +0100

On 2018-01-27 23:24, Carsten Bormann wrote:
> ...
> ...

You can put into a reference whatever you want, so what's the problem here?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Jan 2018 18:15:01 +0100

> You can put into a reference whatever you want, so what's the problem here?

Hi Julian,

I know that you like to manually create the contents of the references sections.

I believe that this is both a waste of time and an inevitable source of clerical errors.

So, when I write a draft, I try to reference bibxml as much as possible (including now the automatically generated bibxml parts for DOIs, which solve 80 % of the cases that used to require manually created references).

When I write *two* drafts that mutually reference each other, to generate one of the drafts, I’d need the bibxml info for the other draft at the time of generation of the draft already.  Now, obviously, that is a catch-22.

What I’m planning to do at some point (when I have a lot of time :-) is write a tool that pre-populates the ~/.cache/xml2rfc with an advance version of the bibxml files that will be generated for a draft to be submitted, allowing two new drafts to reference each other before either of them enters the Internet-Drafts directory and thus (with up to an hour of delay) bibxml.  It’s not too hard to extract the <front> element from the RFCXML of the other, almost complete draft; I just have to do the glue around that right.  It would also be nice to build in some precautions that minimize the clerical errors that this is likely to introduce due to missed updates of the pre-populated information.

(And, to the Subject question: Henrik, can the period maybe be reduced to 30 minutes?)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jan 2018 18:37:37 +0100

> I believe that this is both a waste of time and an inevitable source of clerical errors.

We did it for HTTP and we do it for QUIC... It also helps to make the 
editor's copy point to the editor's copies of the sibling documents -- 
and that's important, isn't it?

Best regards, Julian

---

From: Bob Hinden <[email-masked]>
Date: Sun, 28 Jan 2018 09:49:46 -0800

> On Jan 28, 2018, at 9:37 AM, Julian Reschke <[email-masked]> wrote:
> 
> We did it for HTTP and we do it for QUIC... It also helps to make the editor's copy point to the editor's copies of the sibling documents -- and that's important, isn't it?

I ran into this issue when doing the IPv6 updates with several drafts that reference each other.  I eventually stopped worrying about it, figuring that what was really important was that the published RFC had the correct references.

Bob

> 
>> ...
> 
> Best regards, Julian
> 
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 28 Jan 2018 18:51:25 +0100

Hi Carsten,

> (And, to the Subject question: Henrik, can the period maybe be

Done, the script now starts at *:15 and *:45, and takes about 11 minutes to run.

Long-term, we should find a different solution, as the scripts are old
and (for me, at least) hard-to-maintain TCL.  (From Marshall Rose's time).
Tony Hansen has done an admirable job of keeping them alive.

Best,

	Henrik

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jan 2018 17:18:50 -0500

Carsten Bormann <[email-masked]> wrote:
    > When I write *two* drafts that mutually reference each other, to
    > generate one of the drafts, I’d need the bibxml info for the other
    > draft at the time of generation of the draft already.  Now, obviously,
    > that is a catch-22.

Yeah, I'd think that you have to write them both with no reference and then
interate to get the bibxml available....

    > What I’m planning to do at some point (when I have a lot of time :-) is
    > write a tool that pre-populates the ~/.cache/xml2rfc with an advance
    > version of the bibxml files that will be generated for a draft to be
    > submitted, allowing two new drafts to reference each other before
    > either of them enters the Internet-Drafts directory and thus (with up
    > to an hour of delay) bibxml.  It’s not too hard to extract the <front>

So does DT/biblxml code pull data out of the datatracker, or does it extract
it from the txt or xml files...?
Perhaps xml2rfc should emit the .bibxml3 file for each document...

    > element from the RFCXML of the other, almost complete draft; I just
    > have to do the glue around that right.  It would also be nice to build
    > in some precautions that minimize the clerical errors that this is
    > likely to introduce due to missed updates of the pre-populated
    > information.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Jan 2018 01:12:20 +0100

>> We did it for HTTP and we do it for QUIC... It also helps to make the editor's copy point to the editor's copies of the sibling documents -- and that's important, isn't it?

Sure.  For drafts that are really just sections of a single document, that may work well.  If the coupling is a little less intensive, it becomes more work to coordinate.  In any case, I’d rather continue to do changes in one place only and replicate from there programmatically.

> I ran into this issue when doing the IPv6 updates with several drafts that reference each other.  I eventually stopped worrying about it, figuring that what was really important was that the publis…

Absolutely, not worrying is a valid strategy (which is pretty much what I’ve been doing so far).  I just was thinking about good ways to move beyond that…

(I since wrote the little tool for pre-populating the cache that I outlined in my previous mail, and it will be part of the next version of kramdown-rfc.  No update precautions except for the somewhat aggressive cache retirement that kramdown-rfc uses...)

Grüße, Carsten