[rfc-i] XInclude usage
cabo at tzi.org
Wed Aug 4 22:20:44 PDT 2021
On 5. Aug 2021, at 02:02, Mark Nottingham <mnot at mnot.net> wrote:
> It seems to me that we really need two schema:
> 1) what the RPC accepts as input
> 2) what the RPC publishes as an RFC
> ... because they are getting more different, and trying to accommodate both in a single schema confuses people who want to know what (1) and (2) are definitively.
We definitely need to recognise this split, along with
0) what the tools that people who author RFCs in XML accept/work with.
Clearly, (0) includes XInclude for text files, which is in use for components such as YANG modules.
(The alternative is to use a preprocessor such as custom Makefiles and/or kramdown-rfc to assemble the document, but if we embrace XInclude at all, this is a natural way to use something that more than one XML tool might understand.)
(Note that we have src= attributes in a few places, too, so we already have some custom facility for some applications of this.)
We generally try to inline these includes before handing over to the RPC, but could stop doing this (i.e., add that feature to (1)) if we were to recognize other forms of canonical input.
(2) does not include XInclude.
(The v3.rnc I have been using out of xml2rfc source does not include XInclude, IIRC.)
I’m not going to include the obligatory rant about validation, but want to note that there are a lot of validation rules that would be hard to express in terms of XML validation, e.g., the need for relative= for a section reference if and only if it is not to an IETF document (I-D or RFC).
BTW, introducing custom elements for something that could also be achieved based on some generic mechanism such as XInclude can improve both the author experience in terms of reducing busywork and increasing the benefit of validation (e.g., by specifically identifying a reference to an IETF document as such).
More information about the rfc-interest