[rfc-i] Keeping some of the PIs from v2 in v3, but as an actual part of the grammar
paul.hoffman at vpnc.org
Tue Mar 18 11:23:35 PDT 2014
On Mar 18, 2014, at 10:50 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2014-03-18 18:32, Paul Hoffman wrote:
>> Greetings again. In the v3 format, XML PIs (processor instructions) will be ignored. However, there are some PIs in v2 that are probably useful in v3, mostly for Internet Drafts but a few for producing the non-canonical representations.
> PIs are "processing instructions", and by definition are not part of the vocabulary. It makes no sense to say "they are ignored in the v3 format".
Correct, which is why I didn't say it. I said they "will be ignored", indicating that they will be ignored by processors.
> The TCL code supports a big set of PIs. Some of these are real "instructions to the processor", some are not. I can only speculate why they became PIs; probably because people did not want to touch the DTD.
>> A hopefully-complete list of v2 PIs are at <http://xml.resource.org/authoring/README.html#anchor6>. Many of the PIs on that list are of very marginal value, and given that few people knew of them, can probably be ignored for v3. Some of them are actively harmful for v3, such as those that would suppress valuable information in the non-canonical representations. I believe that the following list could be of value in v3:
> Adopting these IMHO should be the exception, not the rule.
> ...affects list styling, thus should be part of our improved list concept.
Yeeps, correct. In fact, I already have that in the current v3 draft. My mistake for listing it here.
> Optimizes vertical whitespace. We shouldn't need that.
I agree, but didn't want people clamoring for it.
> Are the only allowable format in the style guide anyway.
I wish you were correct, but where in draft-iab-styleguide-01 do you see that? And, even if it is part of the current Style Guide Draft, it is not enforced; see RFC 6892 and 6897.
> Currently, the style guide requires the TOC.
See my message to Andrew; this is not enforced.
> The style guide should be clear about this; in that case we don't need a switch.
That would be nice, yes.
> ...that being said, I note that you didn't list "include" :-)
Correct. Includes could be a security nightmare for the draft submission tool. If someone needs to do includes, they can use their own tooling to make that happen.
>> These could be added as new attributes in the <rfc> element, or could be attributes in an new element that is a child to <rfc>; the former seems easier and not onerous.
> Let's first find out what we need.
More information about the rfc-interest