[rfc-i] How to indent artwork with surrounding block

[brian.e.carpenter at gmail.com (Brian E Carpenter)]

On 18/02/2016 05:28, Julian Reschke wrote:
> On 2016-02-17 17:14, Paul Kyzivat wrote:
>> ...
>> ISTM that <CODE BEGINS> and <CODE ENDS> is generally annoying to read
>> and only needed if there aren't formatting clues to help distinguish
>> code from text. So the formatting of <sourcecode> should largely
>> eliminate the need.
>> ...
> 
> ...unless we have cases where we want to embed <sourcecode> that does *not* qualify as "code component" in the IPR sense.

Which is a *human* decision. What the current Trust legal text says is this:

"Definition. IETF Contributions and IETF Documents often include components intended to be directly processed by a computer
(?Code Components?). A list of common Code Components can be found at http://trustee.ietf.org/license-info/.

Identification. Text in IETF Contributions and IETF Documents of the types identified in Section 4.a above shall constitute
?Code Components?. In addition, any text found between the markers <CODE BEGINS> and <CODE ENDS>, or otherwise clearly labeled
as a Code Component, shall be considered a ?Code Component?."

There's no distinction there between examples and non-examples. It's simply stuff to be
processed by a computer. And the <> markers are optional.

> 
> I recommend to have a look at the set of published RFCs. The <CODE ...> brackets are only used rarely (and, as far as I can
> tell, even in some of these cases might not have been required). Thus they seem to play the role of a seldom-used escape, thus
> IMHO we should do the same in vocabulary and rendering code: do nothing by default, and allow an attribute to override it.
> 
>> If the author has a need to include some form of <CODE BEGINS> and <CODE
>> ENDS> into the <sourcecode> then it ought to be formatted as a comment
>> in the syntax of the code so that the extracted code will be valid.
> 
> Won't work in all formats; example: JSON.

So specifying the markers in xml seems reasonable.

    Brian