[media-types] Filling out templates in XML

Sean Leonard <dev+ietf@seantek.com> Wed, 29 June 2016 03:25 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D880E12D9E5 for <media-types@ietfa.amsl.com>; Tue, 28 Jun 2016 20:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxx1KLYRnahu for <media-types@ietfa.amsl.com>; Tue, 28 Jun 2016 20:25:03 -0700 (PDT)
Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413BA12D9E4 for <media-types@ietf.org>; Tue, 28 Jun 2016 20:25:03 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T3OgD7032420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <media-types@iana.org>; Wed, 29 Jun 2016 03:25:03 GMT
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B113509B5; Tue, 28 Jun 2016 23:24:42 -0400 (EDT)
To: xml2rfc@ietf.org
From: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <be19f1f6-72ad-8a35-3104-f71799703d60@seantek.com>
Date: Tue, 28 Jun 2016 20:24:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 29 Jun 2016 03:25:03 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/7kte6PGXi0xCLYUvUbHPfnTCqZQ>
Cc: "media-types@iana.org" <media-types@iana.org>
Subject: [media-types] Filling out templates in XML
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 03:25:05 -0000

Just curious if people have thought about using XML elements to fill out 
templates, in xml2rfc, rather than sticking the template instance in an 
artwork blob.

Consider <draft-ietf-netconf-restconf-14.xml> (which I just reviewed). 
In #media-types, the RFC 6838 templates are instantiated as artwork. 
Wouldn't it be better to put the things in some basic XML blocks? I have 
seen very long registration templates elsewhere, like URNs and URIs, 
that can spill over to multiple pages. It would be helpful if these 
could be treated (at least in part) as regular runs of text so that they 
are subject to page breaking automatically, etc.

There is a temptation to over-specify the details of every registration 
template. Perhaps a quick survey could be done, to see some common 
IETF/IANA registration templates, and if there is enough common to them 
to permit a small handful of elements. 6 elements or less, I would say. 
For example:

<instance schema="RFC6838">
   <field name="Type name">application</field>
   <field name="Subtype name">yang-data+xml</field>
   <field name="Required parameters">none</field>
   ...
   <field name="Security considerations"><t>Security considerations related
       to the generation and consumption of RESTCONF messages
       are discussed in Section NN of <xref target="RFCXXXX" />.
       Additional security considerations are specific to the
       semantics of particular YANG data models. Each YANG module
       is expected to specify security considerations for the
       YANG data defined in that module.</t>

   <additional>blah blah blah at end of instance</additional>
</instance>

That yields 3 elements: instance, field, and additional.

An alternate approach is to have some XML namespace/schema and embed it 
in a <figure>, similar to <svg> (in <artwork>) and <sourcecode>. Could 
get needlessly complex, but would limit arbitrary placement. Depends on 
whether one feels that registration templates need to be in <figure> 
elements or not. I believe that template instances can be part of the 
main specification text (first, because template instances can contain 
normative specification language; second, because it's possible that 
template fields might have figures inside); therefore, they should not 
be required to be in <figure> elements.

Just my 2¢.

Sean