Re: [xml2rfc] include processing directive

[Erik Wilde <[e-mail]>]

hello nico.

On 2013-11-11, 22:26 , Nico Williams wrote:
> Agreed.  One use case I've seen a few times is where you have a large
> ASN.1/XDR/whatever module that needs to go in an appendix but select
> pieces of which need to be interspersed with the prose for explanatory
> purposes.  Hand-coding this is extremely error prone.  Here the idea
> would be to markup sub-sections of the module but otherwise have it in
> one piece, then reference specific sub-sections of the module as
> desired.  Another possibility is to spread the module throughout the
> source doc and have functionality to pull all the bits, concatenate
> them, then make the result the appendix -- IMO this second approach is
> terrible, but the first approach requires a fairly radical new
> approach to "artwork".

not really. unless you plan on making <artwork> itself inclusion-enabled 
(which i think would not be such a great way to go), you simply use 
XInclude and you're done. this is a working snippet from 
https://github.com/dret/I-D/blob/master/xml-patch/draft-wilde-xml-patch-08.xml, 
which requires XInclude processing (&files; is defined as 
"draft-wilde-xml-patch-08-files" in the XML):

<artwork type="xml"><xi:include parse="text" 
href="&files;/patch-document.xml"/></artwork>

the current downside of XIPr (the XInclude processor i am using, 
https://github.com/dret/XIPr) is that you can only include complete text 
files, and not fragments. XInclude 1.1 fixes that, but i haven't 
implemented it yet. i have no idea how widely 1.1 is supported, but i 
would guess that most current XInclude implementations are 1.0 only. 1.1 
support would allow something like this:

<artwork type="xml"><xi:include parse="text" 
href="&files;/patch-document.xml#line=10,12"/></artwork>

one problem is that if you support 1.1 (i.e., fragments for textual 
inclusion), once you insert one line at the start of your included file, 
you have to adjust all fragment identifiers or they'll "get out of sync" 
(integrity checks http://tools.ietf.org/html/rfc5147#section-3.1 can be 
used to detect this situation, but they won't fix it). there's no easy 
way around this. but apart from that, it's certainly much better than 
what i was doing before, i.e. copy/pasting files into the XML source.

cheers,

dret.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |