[rfc-i] [xml2rfc] use of sourcecode type
henrik at levkowetz.com
Tue Jul 21 09:15:08 PDT 2020
On 2020-07-21 17:48, Paul Kyzivat wrote:
> On 7/21/20 11:10 AM, Carsten Bormann wrote:
>> A similar problem is giving examples that are intentionally bad in order to demonstrate a kind of error.
> Good point.
>> I typically tag them with a type that is derived from the one I would give for real code, e.g., “CDDLx” for a bad CDDL example. I think it would be good to agree on some way to indicate this.
> I agree that we should have some agreed upon way to do this.
> Perhaps a "+xyz" suffix, with some agreed up xyz values.
>> A related problem is that often several code blocks combine to one valid instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428. There is no way to say that Figure 1 and 2 combine into a valid instance, and so do Figure 1 and 3, but not any other combination.
> I'm also interested in this. I believe an obvious solution to this is
> via the "name" attribute. All the ones with the same name should be
> gathered together.
Yes. That's already mentioned in RFC7991:
and also in the documentation for the current xml2rfc release:
> A problem I have with both name and type is that they are invisible in
> the human readable formats. They provide semantic information that may
> be of interest to a reader. Perhaps they could be available in html via
> a popup?
>> And, by the way, those type tags are conventionally lower-cased, but this is not made very explicit; you have to infer that from the list in Section 2.48.4 of RFC 7991 or the RFC editor’s updated copy of that list:
>> (Ha, this doesn’t even have “cddl” in it; I’m not sure how this is updated and whether there shouldn’t really be an IANA registry for these.)
> For these to be useful for any sort of automated processing I think they
> should be standardized. I agree with an IANA registry.
> If we wanted to allow unstandardized usage there could be X- prefixes,
> but we have banned those many other places.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the rfc-interest