[rfc-i] [xml2rfc] use of sourcecode type

Henrik Levkowetz 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:
>> https://www.rfc-editor.org/materials/sourcecode-types.txt
>> (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.
> 	Thanks,
> 	Paul
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200721/4c53427b/attachment.asc>

More information about the rfc-interest mailing list