Henrik et al,

Given that we're goin= g to have multiple source files for a draft or RFC (in the example in this = email, there would be three files, the draft/rfc xml, plus=C2=A0tcp-header.svg and=C2=A0tcp-header.txt), will there be a mechanism for uploading mul= tiple source files? Or will we be zipping them first into an archive?

Just curious.

Thanks,

Andy

On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz <henrik@levkowetz.com> wrote:

On 2018-11-19 18:53, Jim Schaad wrote:
>> -----Original Message-----
>> From: Henrik Levkowetz <henrik@levkowetz.com>
>> Sent: Monday, November 19, 2018 9:32 AM
>> To: Jim Schaad <ietf@augustcellars.com>; xml2rfc-dev@ietf.org
>> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post p= reptool
>>
>> Hi Jim,
>>
>> On 2018-11-19 17:58, Jim Schaad wrote:
>> > I have now created a document that uses SVG and has some ASCI= I art as
>> > a backup and I do not like trying to work with the output tha= t
>> > results.=C2=A0 I also had problems with reading RFC 7991 and = getting the
>> > same answer as Henrik did.
>> >
>> > I am not a big fan of the fact that the SVG is going to be en= coded
>> > into a data URI and placed in the file post preptool as this = is going
>> > to be very hard to try and figure out what the changes are du= ring
>> > AUTH48.=C2=A0 I would also think that the RPC is going to hav= e a hard time
>> > doing anything except ignore the contents of the data URI dur= ing
>> > editing.=C2=A0 I am not even sure that I think they are going= to be very
>> > happy with having to create and replace the data URI at the p= oint in
>> > time that I decide to do a small change and update the SVG wh= ich is
>> embedded there.
>>
>> That makes sense to me.
>>
>> > I would propose that we do the following:
>> >
>> > 1. Add a new element <altArtwork> which contains the sa= me attributes
>> > and content as <artwork> 2.=C2=A0 The it is made "= illegal" to have both a
>> > src attribute and text content at the same time on both <a= rtwork> and
>> > <altArtwork>.
>> > 3.=C2=A0 That those places in the grammar where <artwork&g= t; occurs it be
>> > replaced with=C2=A0 (artwork, altArtwork+).
>> >
>> > I am not sure if that is legal grammar or not.=C2=A0 The inte= nt is to say
>> > that an altArtwork element can only directly follow from an a= rtwork
>> > element (or an altArtwork element).
>> >
>> > This would result in:
>> >
>> > <figure>
>> >=C2=A0 =C2=A0 <name> Packet Layout Diagram</name><= br> >> >=C2=A0 =C2=A0 <artwork src=3D"tcp-header.svg" typ= e=3D"svg"/>
>> >=C2=A0 =C2=A0 <altArtwork src=3D"tcp-header.txt" = type=3D"ascii-art"/> </figure>
>>
>> I think this would make it valid to have only <altArtwork>, = which seems a bit
>> odd -- and how would you distinguish the case where you would want= two
>> successive <artwork> elements rendered?
>
> The intent of my grammar was to say that altArtwork could ONLY follow<= br> > artwork. That mean that a bear altArtwork would not be legal.

Aha, ok.

> You could still do (artwork, altArtwork, artwork) which would be two > artworks in a row with the first one having an alternate but not the > second one.

Understood.

>>
>> I wonder if it could be an alternative to instead let artwork eith= er contain text
>> (the compatibility version) or a set of alternative enclosed artwo= rk elements,
>> where each would need to have the type attribute set, and could on= ly hold
>> content of that type.=C2=A0 A formatter could then pick the altern= ative with the best
>> type for its output format:
>>
>> <figure>
>>=C2=A0 =C2=A0<name> Packet Layout Diagram</name>
>>=C2=A0 =C2=A0<artwork>
>>=C2=A0 =C2=A0 =C2=A0<artwork src=3D"tcp-header.svg" ty= pe=3D"svg"/>
>>=C2=A0 =C2=A0 =C2=A0<artwork src=3D"tcp-header.txt" ty= pe=3D"ascii-art"/>
>>=C2=A0 =C2=A0</artwork>
>> </figure>
>

> I have no problems with this, but worry about the turtles all the way<= br> > down case that this would allow. I had thought about introducing a an<= br> > element that could hold multiple artwork but decided that the way I > outlined would be fewer changes. If the container would called
> something like artGroup then I would have no problems here.

Ack.=C2=A0 Or maybe <artgroup> to match <referencegroup>?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik

>>
>> That would make the case of how to handle multiple successive <= artwork> in a
>> figure or in text unambiguous, and would avoid the extra <altAr= twork>
>> element.
>
> Yeah - but turtles all the way down.
>
> Jim
>
>
>>
>> > This would still allow for a data URI to be used in the origi= nal
>> > source file, although why somebody would is unclear.=C2=A0 Bu= t preptool
>> > would move it from the src attribute to content of the artwor= k (or altArtwork)
>> element.
>> > This will be both easier to edit and easier to review for dif= ferences
>> > during AUTH48.
>>
>> Ack.=C2=A0 I like it (but would prefer to avoid the parallel <a= ltArtwork> element
>> without any enclosing (grouping) element).
>>
>>
>>
>> Best,
>>
>>=C2=A0 =C2=A0 =C2=A0 Henrik
>
>
>

_______________________________________________
xml2rfc-dev mailing list
xml2rfc-dev@ietf.= org
https://www.ietf.org/mailman/listinfo/xml2rfc-dev

--000000000000832bc4057b0a56cd-- From nobody Mon Nov 19 13:50:41 2018 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B312D4E7 for ; Mon, 19 Nov 2018 13:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 17PQcW_BGZ4P for ; Mon, 19 Nov 2018 13:50:33 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76657130DF6 for ; Mon, 19 Nov 2018 13:50:32 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Nov 2018 13:45:13 -0800 From: Jim Schaad To: "'Andrew G. Malis'" , 'Henrik Levkowetz' CC: References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> In-Reply-To: Date: Mon, 19 Nov 2018 13:50:02 -0800 Message-ID: <02f101d48051$d5365100$7fa2f300$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F2_01D4800E.C7142270" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKLEbo+pzPHjNpzoGOJ/fuKthp+uAJvt3qQAiazKCECmis6ygGDH8tGo6TiOgA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 21:50:40 -0000 ------=_NextPart_000_02F2_01D4800E.C7142270 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The answer is yes. But we haven=E2=80=99t worked out what the mechanism = is going to be yet. Another possibility is that something like the = current =E2=80=93exp option will be added to create a single file from = multiple files. =20 Jim =20 =20 From: Andrew G. Malis =20 Sent: Monday, November 19, 2018 12:27 PM To: Henrik Levkowetz Cc: ietf@augustcellars.com; xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post = preptool =20 Henrik et al, =20 Given that we're going to have multiple source files for a draft or RFC = (in the example in this email, there would be three files, the draft/rfc = xml, plus tcp-header.svg and tcp-header.txt), will there be a mechanism = for uploading multiple source files? Or will we be zipping them first = into an archive? =20 Just curious. =20 Thanks, Andy =20 =20 On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz > wrote: On 2018-11-19 18:53, Jim Schaad wrote: >> -----Original Message----- >> From: Henrik Levkowetz > >> Sent: Monday, November 19, 2018 9:32 AM >> To: Jim Schaad >; xml2rfc-dev@ietf.org = =20 >> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post = preptool >>=20 >> Hi Jim, >>=20 >> On 2018-11-19 17:58, Jim Schaad wrote: >> > I have now created a document that uses SVG and has some ASCII art = as >> > a backup and I do not like trying to work with the output that >> > results. I also had problems with reading RFC 7991 and getting the >> > same answer as Henrik did. >> > >> > I am not a big fan of the fact that the SVG is going to be encoded >> > into a data URI and placed in the file post preptool as this is = going >> > to be very hard to try and figure out what the changes are during >> > AUTH48. I would also think that the RPC is going to have a hard = time >> > doing anything except ignore the contents of the data URI during >> > editing. I am not even sure that I think they are going to be very >> > happy with having to create and replace the data URI at the point = in >> > time that I decide to do a small change and update the SVG which is >> embedded there. >>=20 >> That makes sense to me. >>=20 >> > I would propose that we do the following: >> > >> > 1. Add a new element which contains the same = attributes >> > and content as 2. The it is made "illegal" to have both = a >> > src attribute and text content at the same time on both = and >> > . >> > 3. That those places in the grammar where occurs it be >> > replaced with (artwork, altArtwork+). >> > >> > I am not sure if that is legal grammar or not. The intent is to = say >> > that an altArtwork element can only directly follow from an artwork >> > element (or an altArtwork element). >> > >> > This would result in: >> > >> >

>> > Packet Layout Diagram >> > >> > = >>=20 >> I think this would make it valid to have only , which = seems a bit >> odd -- and how would you distinguish the case where you would want = two >> successive elements rendered? >=20 > The intent of my grammar was to say that altArtwork could ONLY follow > artwork. That mean that a bear altArtwork would not be legal. Aha, ok. > You could still do (artwork, altArtwork, artwork) which would be two > artworks in a row with the first one having an alternate but not the > second one.=20 Understood. >>=20 >> I wonder if it could be an alternative to instead let artwork either = contain text >> (the compatibility version) or a set of alternative enclosed artwork = elements, >> where each would need to have the type attribute set, and could only = hold >> content of that type. A formatter could then pick the alternative = with the best >> type for its output format: >>=20 >>

>> Packet Layout Diagram >> >> >> >> >> >=20 > I have no problems with this, but worry about the turtles all the way > down case that this would allow. I had thought about introducing a an > element that could hold multiple artwork but decided that the way I > outlined would be fewer changes. If the container would called > something like artGroup then I would have no problems here. Ack. Or maybe to match ? Henrik >>=20 >> That would make the case of how to handle multiple successive = in a >> figure or in text unambiguous, and would avoid the extra >> element. >=20 > Yeah - but turtles all the way down. >=20 > Jim >=20 >=20 >>=20 >> > This would still allow for a data URI to be used in the original >> > source file, although why somebody would is unclear. But preptool >> > would move it from the src attribute to content of the artwork (or = altArtwork) >> element. >> > This will be both easier to edit and easier to review for = differences >> > during AUTH48. >>=20 >> Ack. I like it (but would prefer to avoid the parallel = element >> without any enclosing (grouping) element). >>=20 >>=20 >>=20 >> Best, >>=20 >> Henrik >=20 >=20 >=20 _______________________________________________ xml2rfc-dev mailing list xml2rfc-dev@ietf.org =20 https://www.ietf.org/mailman/listinfo/xml2rfc-dev ------=_NextPart_000_02F2_01D4800E.C7142270 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The answer = is yes.=C2=A0 But we haven=E2=80=99t worked out what the mechanism is = going to be yet. =C2=A0Another possibility is that something like the = current =E2=80=93exp option will be added to create a single file from = multiple files.

Jim

From: = Andrew G. Malis <agmalis@gmail.com>
Sent: Monday, = November 19, 2018 12:27 PM
To: Henrik Levkowetz = <henrik@levkowetz.com>
Cc: ietf@augustcellars.com; = xml2rfc-dev@ietf.org
Subject: Re: [xml2rfc-dev] Alternate = artwork vocabulary and post preptool

Henrik = et al,

Given that we're going to have multiple source files = for a draft or RFC (in the example in this email, there would be three = files, the draft/rfc xml, plus tcp-header.svg and tcp-header.txt), will = there be a mechanism for uploading multiple source files? Or will we be = zipping them first into an archive?

Just curious.

Thanks,

Andy

On = Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz <henrik@levkowetz.com> = wrote:

On = 2018-11-19 18:53, Jim Schaad wrote:
>> -----Original = Message-----
>> From: Henrik Levkowetz <henrik@levkowetz.com>
>> Sent: Monday, = November 19, 2018 9:32 AM
>> To: Jim Schaad <ietf@augustcellars.com>; xml2rfc-dev@ietf.org
>> Subject: Re: = [xml2rfc-dev] Alternate artwork vocabulary and post preptool
>> =
>> Hi Jim,
>>
>> On 2018-11-19 17:58, Jim = Schaad wrote:
>> > I have now created a document that uses = SVG and has some ASCII art as
>> > a backup and I do not = like trying to work with the output that
>> > results. = I also had problems with reading RFC 7991 and getting the
>> = > same answer as Henrik did.
>> >
>> > I am = not a big fan of the fact that the SVG is going to be = encoded
>> > into a data URI and placed in the file post = preptool as this is going
>> > to be very hard to try and = figure out what the changes are during
>> > AUTH48. I = would also think that the RPC is going to have a hard time
>> = > doing anything except ignore the contents of the data URI = during
>> > editing. I am not even sure that I think = they are going to be very
>> > happy with having to create = and replace the data URI at the point in
>> > time that I = decide to do a small change and update the SVG which is
>> = embedded there.
>>
>> That makes sense to = me.
>>
>> > I would propose that we do the = following:
>> >
>> > 1. Add a new element = <altArtwork> which contains the same attributes
>> > = and content as <artwork> 2. The it is made = "illegal" to have both a
>> > src attribute and = text content at the same time on both <artwork> and
>> = > <altArtwork>.
>> > 3. That those places in = the grammar where <artwork> occurs it be
>> > replaced = with (artwork, altArtwork+).
>> >
>> > I = am not sure if that is legal grammar or not. The intent is to = say
>> > that an altArtwork element can only directly follow = from an artwork
>> > element (or an altArtwork = element).
>> >
>> > This would result = in:
>> >
>> > <figure>
>> = > <name> Packet Layout = Diagram</name>
>> > <artwork = src=3D"tcp-header.svg" type=3D"svg"/>
>> = > <altArtwork src=3D"tcp-header.txt" = type=3D"ascii-art"/> </figure>
>> =
>> I think this would make it valid to have only = <altArtwork>, which seems a bit
>> odd -- and how would = you distinguish the case where you would want two
>> successive = <artwork> elements rendered?
>
> The intent of my = grammar was to say that altArtwork could ONLY follow
> artwork. = That mean that a bear altArtwork would not be legal.

Aha, = ok.

> You could still do (artwork, altArtwork, artwork) which = would be two
> artworks in a row with the first one having an = alternate but not the
> second one. =

Understood.

>>
>> I wonder if it could be = an alternative to instead let artwork either contain text
>> = (the compatibility version) or a set of alternative enclosed artwork = elements,
>> where each would need to have the type attribute = set, and could only hold
>> content of that type. A = formatter could then pick the alternative with the best
>> type = for its output format:
>>
>> = <figure>
>> <name> Packet Layout = Diagram</name>
>> = <artwork>
>> <artwork = src=3D"tcp-header.svg" = type=3D"svg"/>
>> <artwork = src=3D"tcp-header.txt" = type=3D"ascii-art"/>
>> = </artwork>
>> </figure>
>

> = I have no problems with this, but worry about the turtles all the = way
> down case that this would allow. I had thought about = introducing a an
> element that could hold multiple artwork but = decided that the way I
> outlined would be fewer changes. If the = container would called
> something like artGroup then I would have = no problems here.

Ack. Or maybe <artgroup> to match = <referencegroup>?

= Henrik

>>
>> That would make the case of how to = handle multiple successive <artwork> in a
>> figure or in = text unambiguous, and would avoid the extra = <altArtwork>
>> element.
>
> Yeah - but = turtles all the way down.
>
> Jim
>
> =
>>
>> > This would still allow for a data URI to = be used in the original
>> > source file, although why = somebody would is unclear. But preptool
>> > would = move it from the src attribute to content of the artwork (or = altArtwork)
>> element.
>> > This will be both = easier to edit and easier to review for differences
>> > = during AUTH48.
>>
>> Ack. I like it (but would = prefer to avoid the parallel <altArtwork> element
>> = without any enclosing (grouping) element).
>>
>> =
>>
>> Best,
>>
>> = Henrik
>
>
> =

_______________________________________________
xml2rfc-dev = mailing list
xml2rfc-dev@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc-dev

------=_NextPart_000_02F2_01D4800E.C7142270-- From nobody Mon Nov 19 14:56:14 2018 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231D012D4E7 for ; Mon, 19 Nov 2018 14:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8VEypAffKme6 for ; Mon, 19 Nov 2018 14:56:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7638412872C for ; Mon, 19 Nov 2018 14:56:10 -0800 (PST) Received: from h-37-140.a357.priv.bahnhof.se ([94.254.37.140]:58058 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gOsSf-0003wY-D8; Mon, 19 Nov 2018 14:56:10 -0800 To: Jim Schaad , "'Andrew G. Malis'" References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> Cc: xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> Date: Mon, 19 Nov 2018 23:56:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02f101d48051$d5365100$7fa2f300$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C4SgSKGV13PWkV1IuSalgg6debl8tT9Vv" X-SA-Exim-Connect-IP: 94.254.37.140 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, agmalis@gmail.com, ietf@augustcellars.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 22:56:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C4SgSKGV13PWkV1IuSalgg6debl8tT9Vv Content-Type: multipart/mixed; boundary="Ob0rHXeIGeNCOMb0BFe2Wlv0l7I9LUKvr"; protected-headers="v1" From: Henrik Levkowetz To: Jim Schaad , "'Andrew G. Malis'" Cc: xml2rfc-dev@ietf.org Message-ID: <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> In-Reply-To: <02f101d48051$d5365100$7fa2f300$@augustcellars.com> --Ob0rHXeIGeNCOMb0BFe2Wlv0l7I9LUKvr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2018-11-19 22:50, Jim Schaad wrote: > The answer is yes. But we haven=E2=80=99t worked out what the mechanism= is > going to be yet. Another possibility is that something like the > current =E2=80=93exp option will be added to create a single file from > multiple files. The new --prep switch does that (and also a lot of normalization). So even if we don't add alternative upload options, running xml2rfc --pre= p on an xml file will result in a complete standalone uploadable xml file. Henrik > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > From: Andrew G. Malis =20 > Sent: Monday, November 19, 2018 12:27 PM > To: Henrik Levkowetz > Cc: ietf@augustcellars.com; xml2rfc-dev@ietf.org > Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post prepto= ol >=20 > =20 >=20 > Henrik et al, >=20 > =20 >=20 > Given that we're going to have multiple source files for a draft or RFC= (in the example in this email, there would be three files, the draft/rfc= xml, plus tcp-header.svg and tcp-header.txt), will there be a mechanism = for uploading multiple source files? Or will we be zipping them first int= o an archive? >=20 > =20 >=20 > Just curious. >=20 > =20 >=20 > Thanks, >=20 > Andy >=20 > =20 >=20 > =20 >=20 > On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz > wrote: >=20 >=20 > On 2018-11-19 18:53, Jim Schaad wrote: >>> -----Original Message----- >>> From: Henrik Levkowetz > >>> Sent: Monday, November 19, 2018 9:32 AM >>> To: Jim Schaad >; xml2rfc-dev@ietf.org =20 >>> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post prep= tool >>>=20 >>> Hi Jim, >>>=20 >>> On 2018-11-19 17:58, Jim Schaad wrote: >>> > I have now created a document that uses SVG and has some ASCII art = as >>> > a backup and I do not like trying to work with the output that >>> > results. I also had problems with reading RFC 7991 and getting the= >>> > same answer as Henrik did. >>> > >>> > I am not a big fan of the fact that the SVG is going to be encoded >>> > into a data URI and placed in the file post preptool as this is goi= ng >>> > to be very hard to try and figure out what the changes are during >>> > AUTH48. I would also think that the RPC is going to have a hard ti= me >>> > doing anything except ignore the contents of the data URI during >>> > editing. I am not even sure that I think they are going to be very= >>> > happy with having to create and replace the data URI at the point i= n >>> > time that I decide to do a small change and update the SVG which is= >>> embedded there. >>>=20 >>> That makes sense to me. >>>=20 >>> > I would propose that we do the following: >>> > >>> > 1. Add a new element which contains the same attribute= s >>> > and content as 2. The it is made "illegal" to have both = a >>> > src attribute and text content at the same time on both a= nd >>> > . >>> > 3. That those places in the grammar where occurs it be >>> > replaced with (artwork, altArtwork+). >>> > >>> > I am not sure if that is legal grammar or not. The intent is to sa= y >>> > that an altArtwork element can only directly follow from an artwork= >>> > element (or an altArtwork element). >>> > >>> > This would result in: >>> > >>> >

>>> > Packet Layout Diagram >>> > >>> > >>>=20 >>> I think this would make it valid to have only , which see= ms a bit >>> odd -- and how would you distinguish the case where you would want tw= o >>> successive elements rendered? >>=20 >> The intent of my grammar was to say that altArtwork could ONLY follow >> artwork. That mean that a bear altArtwork would not be legal. >=20 > Aha, ok. >=20 >> You could still do (artwork, altArtwork, artwork) which would be two >> artworks in a row with the first one having an alternate but not the >> second one.=20 >=20 > Understood. >=20 >>>=20 >>> I wonder if it could be an alternative to instead let artwork either = contain text >>> (the compatibility version) or a set of alternative enclosed artwork = elements, >>> where each would need to have the type attribute set, and could only = hold >>> content of that type. A formatter could then pick the alternative wi= th the best >>> type for its output format: >>>=20 >>>

>>> Packet Layout Diagram >>> >>> >>> >>> >>> >>=20 >=20 >> I have no problems with this, but worry about the turtles all the way >> down case that this would allow. I had thought about introducing a an >> element that could hold multiple artwork but decided that the way I >> outlined would be fewer changes. If the container would called >> something like artGroup then I would have no problems here. >=20 > Ack. Or maybe to match ? >=20 > Henrik >=20 >>>=20 >>> That would make the case of how to handle multiple successive in a >>> figure or in text unambiguous, and would avoid the extra = >>> element. >>=20 >> Yeah - but turtles all the way down. >>=20 >> Jim >>=20 >>=20 >>>=20 >>> > This would still allow for a data URI to be used in the original >>> > source file, although why somebody would is unclear. But preptool >>> > would move it from the src attribute to content of the artwork (or = altArtwork) >>> element. >>> > This will be both easier to edit and easier to review for differenc= es >>> > during AUTH48. >>>=20 >>> Ack. I like it (but would prefer to avoid the parallel = element >>> without any enclosing (grouping) element). >>>=20 >>>=20 >>>=20 >>> Best, >>>=20 >>> Henrik >>=20 >>=20 >>=20 >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org =20 > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 >=20 --Ob0rHXeIGeNCOMb0BFe2Wlv0l7I9LUKvr-- --C4SgSKGV13PWkV1IuSalgg6debl8tT9Vv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlvzP4EACgkQTptXS4+7 FxpaAhAAhhnr+RCFfowPKIWYyn78oCBV3jLs8XHZSSArTkEPT8Ix7PlJYA4XM6QM rwWxLwnHdz7KNbIqESTFxNlj/VNGg09b5nOKM7rkNd7BetE70JWS9gFi13bLhCZq vHdIkfQ84MylR/XP2qy5d3jyZpybpQGVPVhCu7MS/Z0D4lD/4RK3/vszFu1fuO0F t1omQmGWcwbZOvNlhosXTiUFjGVE058iDVcBTmoNd0oxXBoaBN9auwDeNdX0+KtX nLmjn8jTSwYsJq7KXkoc96SDP9Mkp1X1V3d1TxANLzge7EKG87kok7Rlbbxg2tVd mwe34gQEv8bGw1JIovVs757z71ZSgjwEiqPdy1s0ssryn0PhWuJhODoytbPLvK/T aq8KF3PKuzSl6Dd3hCdTGDS5Q8VIIWkHwRCPFZBV8ydAfY3QJK1jGUMQDQyh/ZU3 chO6Ct4IQA0tZK97hBRBUWgYI9Q8oil9XYND1WDq5MWCzczCZVbvwczAWRswRXZg D+c47s9ju93LrCMqin3ThkS1XG8QvRMVfpr/eACo7jGbwsD5VLhKJD1HYU91Pw28 4aRdO4EgC46k5JczTSWkFZEn7qb/DMDzA2E8+EwLoNWflWDRVLaMozMGqo3E40tb ynLOJKJ2D/q5/Eqw/QnwHlGAcOhFujCORHUyLHy5HpaidCTaasg= =roM/ -----END PGP SIGNATURE----- --C4SgSKGV13PWkV1IuSalgg6debl8tT9Vv-- From nobody Tue Nov 20 05:11:10 2018 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8D0130E1A for ; Tue, 20 Nov 2018 05:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xYFq419H767d for ; Tue, 20 Nov 2018 05:11:05 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9739129619 for ; Tue, 20 Nov 2018 05:11:04 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id m5so2647153qka.9 for ; Tue, 20 Nov 2018 05:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qbi6i4r1D6LSV8xx1vcCOCPrZXYagwzghC/3kcv1cJw=; b=B/Gf2xJFwtOGJJ8+038vwSvuds7pPghwsI2QHGyNfU7oSCFeJ4SjcoV+rqcljYQyX4 yTHBVgMBb15yvDnuTQJTTbt5akD1FMmCHCbHV4Tjo5/Po6aaLj8ZjOwuFaWdZSc5dnDB DhPCrvTi4/RFHmpPlErfQ+ukl417QtH5zZk6rBShG11CPF0M7ziEFjOgAVXEYooDV3kQ fkoxe6G3Se+TaD613Sof+BcFhqxA57GxxmahSBac58WtbeWFIFVLej8xrgPen4tabDFA 4pPYb4cRZ2+mgCekCZg3J2ngXhJMu51O5zrXOajZ3lAaEISc6OYK9E7VQHy5JQtG8N42 6KaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qbi6i4r1D6LSV8xx1vcCOCPrZXYagwzghC/3kcv1cJw=; b=rzRMNmRwlDujndyNh31pX6gG/pTdd0+jwx8Iy/2JeYu9EmcVZVdDFDQPwVNbnh9yFe hh0owOMkGwGPRcC4LFWk2jSANT96qzaq7GzkmK16zRiEXcDCgc6ktclANyFUvEo/bzS0 9jEH1Af+3foJ984DLOyntAYBcz6eVA0WxpVsJTgS/TmzJvu3aarnorXRRu+KwfxxcM4/ bJ4Cz90U1/q2TQ3RJpLXiAmBe2MEAS/+X6kOGP3HnRPv8009EQe1UV6HPJtcJs91R+YN hd4xixaGcFFZ/AqKnj8sP8jw9FHl9HLG6P/qk4L8EvAzN2LEYrg6z0+lV6MuX3YbfAqu I26A== X-Gm-Message-State: AGRZ1gKIBBsfuaXEqH6RLH8feGr7arlhalGsxhIBvRZ+js7vtm+2k3Qy lMTIV85rZgXZND+nD4jKWUF3mfyxm19gQGkhpM+fPw== X-Google-Smtp-Source: AJdET5finDsVvys75ZCLLRJGL1ymtZeHYMVyI/c0P05JEEMxfhVHkiIKLCL8O3i21F1CC8Vpz4gFBEuTIDMeN3qNSa8= X-Received: by 2002:ac8:5156:: with SMTP id h22mr1719674qtn.81.1542719463686; Tue, 20 Nov 2018 05:11:03 -0800 (PST) MIME-Version: 1.0 References: <02ad01d48029$116c1f20$34445d60$@augustcellars.com> <8aabb843-e60f-adb2-092b-c0df9224bac3@levkowetz.com> <02bb01d48030$d76bf8b0$8643ea10$@augustcellars.com> <01370848-07a2-0abd-e4b4-473489d89cd5@levkowetz.com> <02f101d48051$d5365100$7fa2f300$@augustcellars.com> <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> In-Reply-To: <021ed6ef-4a84-5e01-7dd4-22559f40e3b6@levkowetz.com> From: "Andrew G. Malis" Date: Tue, 20 Nov 2018 08:10:52 -0500 Message-ID: To: Henrik Levkowetz Cc: ietf@augustcellars.com, xml2rfc-dev@ietf.org Content-Type: multipart/alternative; boundary="0000000000009f081b057b185d25" Archived-At: Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 13:11:09 -0000 --0000000000009f081b057b185d25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Henrik, That makes sense, thanks! Cheers, Andy On Mon, Nov 19, 2018 at 5:56 PM Henrik Levkowetz wrote: > > On 2018-11-19 22:50, Jim Schaad wrote: > > The answer is yes. But we haven=E2=80=99t worked out what the mechanism= is > > going to be yet. Another possibility is that something like the > > current =E2=80=93exp option will be added to create a single file from > > multiple files. > > The new --prep switch does that (and also a lot of normalization). > > So even if we don't add alternative upload options, running xml2rfc --pre= p > on an xml file will result in a complete standalone uploadable xml file. > > > Henrik > > > > > > > > Jim > > > > > > > > > > > > From: Andrew G. Malis > > Sent: Monday, November 19, 2018 12:27 PM > > To: Henrik Levkowetz > > Cc: ietf@augustcellars.com; xml2rfc-dev@ietf.org > > Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post prepto= ol > > > > > > > > Henrik et al, > > > > > > > > Given that we're going to have multiple source files for a draft or RFC > (in the example in this email, there would be three files, the draft/rfc > xml, plus tcp-header.svg and tcp-header.txt), will there be a mechanism f= or > uploading multiple source files? Or will we be zipping them first into an > archive? > > > > > > > > Just curious. > > > > > > > > Thanks, > > > > Andy > > > > > > > > > > > > On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz > wrote: > > > > > > On 2018-11-19 18:53, Jim Schaad wrote: > >>> -----Original Message----- > >>> From: Henrik Levkowetz henrik@levkowetz.com> > > >>> Sent: Monday, November 19, 2018 9:32 AM > >>> To: Jim Schaad > >; xml2rfc-dev@ietf.org > >>> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post > preptool > >>> > >>> Hi Jim, > >>> > >>> On 2018-11-19 17:58, Jim Schaad wrote: > >>> > I have now created a document that uses SVG and has some ASCII art = as > >>> > a backup and I do not like trying to work with the output that > >>> > results. I also had problems with reading RFC 7991 and getting the > >>> > same answer as Henrik did. > >>> > > >>> > I am not a big fan of the fact that the SVG is going to be encoded > >>> > into a data URI and placed in the file post preptool as this is goi= ng > >>> > to be very hard to try and figure out what the changes are during > >>> > AUTH48. I would also think that the RPC is going to have a hard ti= me > >>> > doing anything except ignore the contents of the data URI during > >>> > editing. I am not even sure that I think they are going to be very > >>> > happy with having to create and replace the data URI at the point i= n > >>> > time that I decide to do a small change and update the SVG which is > >>> embedded there. > >>> > >>> That makes sense to me. > >>> > >>> > I would propose that we do the following: > >>> > > >>> > 1. Add a new element which contains the same attribute= s > >>> > and content as 2. The it is made "illegal" to have both = a > >>> > src attribute and text content at the same time on both a= nd > >>> > . > >>> > 3. That those places in the grammar where occurs it be > >>> > replaced with (artwork, altArtwork+). > >>> > > >>> > I am not sure if that is legal grammar or not. The intent is to sa= y > >>> > that an altArtwork element can only directly follow from an artwork > >>> > element (or an altArtwork element). > >>> > > >>> > This would result in: > >>> > > >>> >

> >>> > Packet Layout Diagram > >>> > > >>> > > >>> > >>> I think this would make it valid to have only , which > seems a bit > >>> odd -- and how would you distinguish the case where you would want tw= o > >>> successive elements rendered? > >> > >> The intent of my grammar was to say that altArtwork could ONLY follow > >> artwork. That mean that a bear altArtwork would not be legal. > > > > Aha, ok. > > > >> You could still do (artwork, altArtwork, artwork) which would be two > >> artworks in a row with the first one having an alternate but not the > >> second one. > > > > Understood. > > > >>> > >>> I wonder if it could be an alternative to instead let artwork either > contain text > >>> (the compatibility version) or a set of alternative enclosed artwork > elements, > >>> where each would need to have the type attribute set, and could only > hold > >>> content of that type. A formatter could then pick the alternative > with the best > >>> type for its output format: > >>> > >>>

> >>> Packet Layout Diagram > >>> > >>> > >>> > >>> > >>> > >> > > > >> I have no problems with this, but worry about the turtles all the way > >> down case that this would allow. I had thought about introducing a an > >> element that could hold multiple artwork but decided that the way I > >> outlined would be fewer changes. If the container would called > >> something like artGroup then I would have no problems here. > > > > Ack. Or maybe to match ? > > > > Henrik > > > >>> > >>> That would make the case of how to handle multiple successive > in a > >>> figure or in text unambiguous, and would avoid the extra > >>> element. > >> > >> Yeah - but turtles all the way down. > >> > >> Jim > >> > >> > >>> > >>> > This would still allow for a data URI to be used in the original > >>> > source file, although why somebody would is unclear. But preptool > >>> > would move it from the src attribute to content of the artwork (or > altArtwork) > >>> element. > >>> > This will be both easier to edit and easier to review for differenc= es > >>> > during AUTH48. > >>> > >>> Ack. I like it (but would prefer to avoid the parallel > element > >>> without any enclosing (grouping) element). > >>> > >>> > >>> > >>> Best, > >>> > >>> Henrik > >> > >> > >> > > > > _______________________________________________ > > xml2rfc-dev mailing list > > xml2rfc-dev@ietf.org > > https://www.ietf.org/mailman/listinfo/xml2rfc-dev > > > > > > --0000000000009f081b057b185d25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Henrik,

That makes sense, thanks!

Cheers,

Andy

On Mon, Nov 19, 2018 at 5:56 PM H= enrik Levkowetz <henrik@levkowet= z.com> wrote:

On 2018-11-19 22:50, Jim Schaad wrote:
> The answer is yes. But we haven=E2=80=99t worked out what the mechanis= m is
> going to be yet. Another possibility is that something like the
> current =E2=80=93exp option will be added to create a single file from=
> multiple files.

The new --prep switch does that (and also a lot of normalization).

So even if we don't add alternative upload options, running xml2rfc --p= rep
on an xml file will result in a complete standalone uploadable xml file.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik

>=C2=A0
>
> Jim
>
>=C2=A0
>
>=C2=A0
>
> From: Andrew G. Malis <agmalis@gmail.com>
> Sent: Monday, November 19, 2018 12:27 PM
> To: Henrik Levkowetz <henrik@levkowetz.com>
> Cc: ietf@a= ugustcellars.com; xml2rfc-dev@ietf.org
> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post prept= ool
>
>=C2=A0
>
> Henrik et al,
>
>=C2=A0
>
> Given that we're going to have multiple source files for a draft o= r RFC (in the example in this email, there would be three files, the draft/= rfc xml, plus tcp-header.svg and tcp-header.txt), will there be a mechanism= for uploading multiple source files? Or will we be zipping them first into= an archive?
>
>=C2=A0
>
> Just curious.
>
>=C2=A0
>
> Thanks,
>
> Andy
>
>=C2=A0
>
>=C2=A0
>
> On Mon, Nov 19, 2018 at 1:47 PM Henrik Levkowetz <henrik@levkowetz.com <mailt= o:henrik@levkowet= z.com> > wrote:
>
>
> On 2018-11-19 18:53, Jim Schaad wrote:
>>> -----Original Message-----
>>> From: Henrik Levkowetz <henrik@levkowetz.com <mailto:henrik@levkowetz.com> >=
>>> Sent: Monday, November 19, 2018 9:32 AM
>>> To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >= ; xml2rfc-dev@iet= f.org <mailto:xml2rfc-dev@ietf.org>
>>> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and po= st preptool
>>>
>>> Hi Jim,
>>>
>>> On 2018-11-19 17:58, Jim Schaad wrote:
>>> > I have now created a document that uses SVG and has some = ASCII art as
>>> > a backup and I do not like trying to work with the output= that
>>> > results.=C2=A0 I also had problems with reading RFC 7991 = and getting the
>>> > same answer as Henrik did.
>>> >
>>> > I am not a big fan of the fact that the SVG is going to b= e encoded
>>> > into a data URI and placed in the file post preptool as t= his is going
>>> > to be very hard to try and figure out what the changes ar= e during
>>> > AUTH48.=C2=A0 I would also think that the RPC is going to= have a hard time
>>> > doing anything except ignore the contents of the data URI= during
>>> > editing.=C2=A0 I am not even sure that I think they are g= oing to be very
>>> > happy with having to create and replace the data URI at t= he point in
>>> > time that I decide to do a small change and update the SV= G which is
>>> embedded there.
>>>
>>> That makes sense to me.
>>>
>>> > I would propose that we do the following:
>>> >
>>> > 1. Add a new element <altArtwork> which contains th= e same attributes
>>> > and content as <artwork> 2.=C2=A0 The it is made &q= uot;illegal" to have both a
>>> > src attribute and text content at the same time on both &= lt;artwork> and
>>> > <altArtwork>.
>>> > 3.=C2=A0 That those places in the grammar where <artwo= rk> occurs it be
>>> > replaced with=C2=A0 (artwork, altArtwork+).
>>> >
>>> > I am not sure if that is legal grammar or not.=C2=A0 The = intent is to say
>>> > that an altArtwork element can only directly follow from = an artwork
>>> > element (or an altArtwork element).
>>> >
>>> > This would result in:
>>> >
>>> > <figure>
>>> >=C2=A0 =C2=A0 <name> Packet Layout Diagram</name&= gt;
>>> >=C2=A0 =C2=A0 <artwork src=3D"tcp-header.svg"= type=3D"svg"/>
>>> >=C2=A0 =C2=A0 <altArtwork src=3D"tcp-header.txt&qu= ot; type=3D"ascii-art"/> </figure>
>>>
>>> I think this would make it valid to have only <altArtwork&g= t;, which seems a bit
>>> odd -- and how would you distinguish the case where you would = want two
>>> successive <artwork> elements rendered?
>>
>> The intent of my grammar was to say that altArtwork could ONLY fol= low
>> artwork. That mean that a bear altArtwork would not be legal.
>
> Aha, ok.
>
>> You could still do (artwork, altArtwork, artwork) which would be t= wo
>> artworks in a row with the first one having an alternate but not t= he
>> second one.
>
> Understood.
>
>>>
>>> I wonder if it could be an alternative to instead let artwork = either contain text
>>> (the compatibility version) or a set of alternative enclosed a= rtwork elements,
>>> where each would need to have the type attribute set, and coul= d only hold
>>> content of that type.=C2=A0 A formatter could then pick the al= ternative with the best
>>> type for its output format:
>>>
>>> <figure>
>>>=C2=A0 =C2=A0<name> Packet Layout Diagram</name> >>>=C2=A0 =C2=A0<artwork>
>>>=C2=A0 =C2=A0 =C2=A0<artwork src=3D"tcp-header.svg"= ; type=3D"svg"/>
>>>=C2=A0 =C2=A0 =C2=A0<artwork src=3D"tcp-header.txt"= ; type=3D"ascii-art"/>
>>>=C2=A0 =C2=A0</artwork>
>>> </figure>
>>
>
>> I have no problems with this, but worry about the turtles all the = way
>> down case that this would allow. I had thought about introducing a= an
>> element that could hold multiple artwork but decided that the way = I
>> outlined would be fewer changes. If the container would called
>> something like artGroup then I would have no problems here.
>
> Ack.=C2=A0 Or maybe <artgroup> to match <referencegroup>?<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Henrik
>
>>>
>>> That would make the case of how to handle multiple successive = <artwork> in a
>>> figure or in text unambiguous, and would avoid the extra <a= ltArtwork>
>>> element.
>>
>> Yeah - but turtles all the way down.
>>
>> Jim
>>
>>
>>>
>>> > This would still allow for a data URI to be used in the o= riginal
>>> > source file, although why somebody would is unclear.=C2= =A0 But preptool
>>> > would move it from the src attribute to content of the ar= twork (or altArtwork)
>>> element.
>>> > This will be both easier to edit and easier to review for= differences
>>> > during AUTH48.
>>>
>>> Ack.=C2=A0 I like it (but would prefer to avoid the parallel &= lt;altArtwork> element
>>> without any enclosing (grouping) element).
>>>
>>>
>>>
>>> Best,
>>>
>>>=C2=A0 =C2=A0 =C2=A0 Henrik
>>
>>
>>
>
> _______________________________________________
> xml2rfc-dev mailing list
> xml2rfc-dev@= ietf.org <mailto:xml2rfc-dev@ietf.org>
> https://www.ietf.org/mailman/listinfo/xml2rfc-= dev
>
>