Re: [Xml-sg-cmt] Please consider adding a way to speak about references as a token to the grammar

[Robert Sparks <[e-mail]>]

On 3/5/22 7:10 PM, John R Levine wrote:
> On Sat, 5 Mar 2022, Robert Sparks wrote:
>> I think that's an orthogonal discussion. _Just_ having that anchor 
>> doesn't address the full benefit I think I see from not having such 
>> an explicit path - particularly when we get to trying to make it easy 
>> for working copies to continue to have pointers while the repository 
>> has resolved content.
>
> Something is going to have to know where the bibxml files are, and 
> either we figure out how to maintain a list of stable URLs or we need 
> to manage the list of tools that know where they are, and how we are 
> going to update them all and push out the updates to all of the users 
> when the tools change.
A much more tractable problem (tens of these things) than the current 
state of managing this information in the thousands of author's heads.
>
> Doing it this way at least makes it obvious what is broken and what 
> you need to fix if they move:
>
> <references xml:base="https://bibxml.ietf.org/">
>   <xi:include href="I-D.sparks-sipcore-multiple-reasons"/>
>   <xi:include href="RFC2549"/>
> </references>
>
> In your proposal with the link in the reference, would it 
> automagically replace the link with the contents when an I-D is 
> submitted, or when it's rendered, or when it's prepped,, or add the 
> contents and keep the link so it could update later if the library 
> changes, or something else?

It would expand the reference pointer , but leave it in the source as a 
comment, structured such that it makes it easy for another program to 
remove what resulted from the expansion, and restore the pointer.

The biggest goal here is to make it easier for authors to continue to 
maintain their source in a way that has indirection to references while 
allowing us to make draft-submission more accurate than it currently is.

There are secondary, but large goals.

1) Right now the URL structure the older bibxml service uses suffers 
from having to build a really arcane bit of structure into the tag 
that's used to distinguish between "give me a particular version of a 
draft" and "give me the latest version of the draft". At 
xml2rfc.tools.ietf.org, references that start 'I-D.draft-' are always 
references to a specific version, and references that start 'I-D.ietf-' 
or 'I-D.name-' are to the latest version. The datatracker's bibxml3 
service and the new bibxml service are currently different - they will 
take the token and look for a version match and return that if there is 
one, and then look to see if it matches a draft name without a version, 
returning the latest if there is a match. In both ways of doing things, 
there is a level of complexity that is unkind to the authors (and the 
coders - the guessing heuristics for finding 'latest' are ugly - people 
have submitted drafts that look like draft-foo-bar-21-22-23). I would 
_much_ rather that we provided the authors a way to explicitly say what 
they want rather than relying on side effect. Mocking up an alternate 
future again, I would like to see something like:

<reference type='I-D' name='draft-foo-bar'> for 'current' and <reference 
type='I-D' name='draft-foo-bar' rev='08'> for a specific version.

We could encode this things back into URL paths and do something like 
what you have above, but then people have to learn the conventions of 
what bit of info lives in what place in the url path, where something 
like the above makes the statement very explicit.

2) For xml2rfc, internally, we plan to use the API that's been developed 
(https://dev.bibxml.org/api/v1/) rather than the current url based form 
for retrieval. We'll be converting URL when given. Yes, I realize that 
we'll always need to be able to recognize the older hosts and paths, so 
that code will be with us anyhow, but I still think we'd be much better 
off going forward with something that allowed the kind of explicit and 
self-documenting statement in 1).

RjS

>
> R's,
> John
>