Subject: [xml2rfc] request for anchor query magic

From: Sean Leonard <[email-masked]>
Date: Wed, 8 Jun 2016 09:46:38 -0700

To Citations:

I have a further request, that you add some server side code for "anchor 
query magic".

Right now, reference anchors like "ITU.X690.1994" are fixed and ugly. 
Please enable substitution query logic, such that the anchor can be 
manipulated by GET request. For example:

http://xml2rfc.ietf.org/public/rfc/bibxml2/reference.ITU.X.690.2015.xml?anchor=X.690

When the resource is GET-ted, the anchor parameter substitutes the 
anchor in at <reference anchor="%ANCHOR%">. In a safe way, of course. 
This would be really helpful, especially for things like 
Internet-Drafts, which have really ugly anchor names by default. When 
the anchor query is not present, it just returns the default, 
unsubstituted resource data.

For example:

http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-urnbis-rfc2141bis-urn-16.xml

could be:

http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-urnbis-rfc2141bis-urn-16.xml?anchor=URNBIS

etc.

Thank you,

Sean

---

From: Julian Reschke <[email-masked]>
Date: Wed, 8 Jun 2016 20:15:12 +0200

> http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-urnbis-rfc2141bis-urn-16.xml?anchor=URNBIS

FWIW; we tried to address this use case in the v3 vocab with 
<https://greenbytes.de/tech/webdav/draft-iab-xml2rfc-03.html#element.displayreference>.

What you propose of course would work right away, but would make the 
server side implementation more tricky with respect to caching / serving 
static files...

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Wed, 8 Jun 2016 23:41:15 -0700

On 6/8/2016 11:15 AM, Julian Reschke wrote:
> server side implementation more tricky with respect to caching / 
> serving static files...

Ok, thanks for the tip. I think that the "query magic" may serve the 
purpose that displayreference does, while being more elegant. Actually 
the underlying problem is that while the rest of the <reference> matter 
is pretty invariant, the @anchor attribute represents more of an 
author's local preference (@anchor was and is never intended to be a 
globally unique string). So it's a bit of a data model problem. Maybe it 
would have made some sense to have the entity reference be the contents 
of the <reference>, such as:
<reference anchor="foo">&RFC5555contents;</reference>

But, that ship sailed away a long time ago.

Can't say much about the caching/serving issue, except that it's pretty 
well-studied computer science territory, so it's doable.

Best regards,

Sean

---

From: Julian Reschke <[email-masked]>
Date: Thu, 9 Jun 2016 08:49:42 +0200

On 2016-06-09 08:41, Sean Leonard wrote:
> ...

Well, those files could be served as well (as static files), but then 
we'd lose the target attribute.

> well-studied computer science territory, so it's doable.

It is. Maybe you want to assist the tools team to get this implemented 
properly? I'm all for it...

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Wed, 8 Jun 2016 23:54:51 -0700

> we'd lose the target attribute.

Yes. A data model issue. I still don't quite understand the practical 
differences between @target and <format> in <reference>.

Except that <format> is deprecated in xml2rfc v3...this would have been 
a good reason to shift the deprecation around...oh well...

> properly? I'm all for it...

I suppose I can help, assuming that there is sufficient consensus that 
this is a good idea and is useful to various parties.

Best regards,

Sean