Re: [rfc-i] XInclude usage

[tjw ietf <[e-mail]>]

> On Aug 4, 2021, at 22:44, Jay Daley <[e-mail]> wrote:
> 
> Hi Peter
> 
> One of my high level concerns about RFC XML is that it should use a formally defined syntax and thereby support validation by a range of common XML tools, not just xml2rfc.  Another one is that if we’re going to use XML then we should use XML and not some custom simulacrum that looks like it but doesn’t walk like it, because then we lose the power of the many XML processing tools out there.

Strongly agree with jay here.  

RFCXML should not be some snowflake.  

Tim 



> 
> In that regard, imposing any limitations on XInclude is problematic because it means that either only xml2rfc can validate a document, or we need to define our own inclusion mechanism (e.g. RFCInclude) that can be validated.  My strong preference would therefore be not to limit XInclude as per your a., b. and c. below.  
> 
> I'm also not clear why we need to limit XInclude this way.  When XInclude is used, it introduces a double validation step, one before the XInclude is processed and one after it is processed.  This can’t really be avoided.  If XInclude is used incorrectly then the second validation will pick that up.  For example, DocBook does not include XInclude in its syntax [1] and only validates the XML that is constructed *after* any XInclude statements are processed and the contents inserted.   
> 
> However, we really should examine if we need XInclude or not.  A good example is the way we include IPR boilerplate, which is by an attribute not any form of XML inclusion.  (BTW By doing this we have effectively created two separate XML vocabularies, as Mark was highlighting, and forced the usage of our custom processor, xml2rfc, to get from one to the other).  We could take a similar approach for BibXML references and define a syntax whereby they are simply identified by name and our custom processor inserts them at the right stage.  We already have a 'database' of BibXML references that this name could be used as the key for and we could provide a mechanism for people to add new references to that if needed.
> 
> 
>>> On 5/08/2021, at 5:51 AM, Peter Saint-Andre <[e-mail]> wrote:
>>> 
>>> Back in 2017, Julian Reschke asked [1] that we clarify the scope of
>>> XInclude [2] usage, to wit:
>>> 
>>> ###
>>> 
>>> 1. It should be clarified how much of XInclude needs to be supported.
>>> I'm mentioning this because RFC7991 says that includes can not happen
>>> where no elements are allowed, but XInclude allows inclusion of plain
>>> text as well.
>>> 
>>> 2. Is support of the xpointer attribute required?
>> 
>> see above
>> 
>> If so, do we have any
>> guidance how this will work when the document from which to include uses
>> xml2rfc format, and the pointer relies on the id-ness of an attribute?
> 
> I need to think this through more, but it would be useful to understand the use case given that RFCs are immutable, so is this only for I-Ds and why are people doing it?
> 
> [1]  http://www.sagehill.net/docbookxsl/ValidXinclude.html
> 
> Jay 
> 
>> 
>> ###
>> 
>> We discussed this recently [3] within the RFC XML and Style Guide Change
>> Management Team. Our understanding is that x:include is used primarily
>> or perhaps exclusively to pull in reference files structured as XML. In
>> order to keep things as simple as possible, my suggestion to the team
>> and to this list is as follows:
>> 
>> a. Limit the usage of XInclude to XML only (parse="xml"), not arbitrary
>> text (parse="text")
>> 
>> b. Don't support fallback [4]
>> 
>> c. Don't support XPointer [5]
>> 
>> I'm curious what others think.
>> 
>> Peter
>> 
>> [1] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/18 see
>> also https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/128
>> [2] https://www.w3.org/TR/2006/REC-xinclude-20061115/
>> [3] https://codimd.ietf.org/cmt-20210726
>> [4] https://www.w3.org/TR/2006/REC-xinclude-20061115/#fallback
>> [5] https://www.w3.org/TR/2003/REC-xptr-framework-20030325/
>> 
>> _______________________________________________
>> rfc-interest mailing list
>> [e-mail]
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>> 
> 
> -- 
> Jay Daley
> IETF Executive Director
> [e-mail]
> 
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest