Re: [Tools-discuss] bibxml3 database reload frequency

[Henrik Levkowetz <[e-mail]>]

On 2020-08-21 07:48, Carsten Bormann wrote:
> On 2020-08-21, at 00:24, Kent Watsen <[e-mail]> wrote:
>> 
>> It worked, and then it didn’t. 
> 
> Yes.  One of the features and bugs of uploading XML is that you rely on the server-side XML2RFC to do your processing for you.  Here it seems, that still had -17 in its cache.
> 
> The kramdown-rfc process has a setting, “stand_alone: true”, which asks kramdown-rfc to resolve any external nreferences.  This is what I recommend people to use.  (It is not the default only because kramdown-rfc tries to support the long document development times typical for the IETF by being insanely backwards-compatible.)
> 
> To get the same level of assurance out of XML authoring, you need to prep the XML before uploading.
> 
> 	xml2rfc --preptool foo.xml

Since release 2.44.0 in April this year, --expand is a much better option,
as it leaves a file that can still be worked with (--preptool expands all
attribute default values, adds ToC xml, and a lot of other things that you
don't really want in a document you might want to edit later).

> 
> You then have a foo.prepped.xml that you can upload.
> (This step is also needed with any local references to SVG, source-code etc.)
> 
> Note that prepping means the uploaded XML is less useful for the RFC
> editor. So, ironically, despite the switch to XML uploading, you will
> want to provide an unprepped XML, as well as all the locally
> referenced files, to the RFC editor -- even though the approved, but
> prepped, XML is in the I-D repository. But this is irrelevant during
> the document development process up to approval.

The --expand option should avoid these drawbacks.

> Ultimately, I hope that xml2rfc gains a reference resolution function
> that does not involve all the preptool processing. For now, prepping
> it is.

Maybe try --expand?


Regards,

	Henrik