[rfc-i] Preparing for allowing v3 submissions into the repository (was Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool)

Robert Sparks rjsparks at nostrum.com
Thu Feb 7 12:07:50 PST 2019


The change proposed in this thread (to allow the preptool to incorporate 
SVG from external files as artwork rather than a data URI) seems right, 
and important.

The IESG is ready to allow v3 submissions into the repository as soon as 
the tooling is ready. The tooling is very close. As noted in the thread, 
our goal is to have the submission tool accept a standalone file (rather 
than solve how to allow submission of multiple components.)

I'm asking that this change be made to the toolchain.

RjS

On 11/20/18 7:10 AM, Andrew G. Malis wrote:
> Henrik,
>
> That makes sense, thanks!
>
> Cheers,
> Andy
>
>
> On Mon, Nov 19, 2018 at 5:56 PM Henrik Levkowetz <henrik at levkowetz.com 
> <mailto:henrik at levkowetz.com>> wrote:
>
>
>     On 2018-11-19 22:50, Jim Schaad wrote:
>     > The answer is yes. But we haven’t worked out what the mechanism is
>     > going to be yet. Another possibility is that something like the
>     > current –exp 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 --prep
>     on an xml file will result in a complete standalone uploadable xml
>     file.
>
>
>             Henrik
>
>
>     >
>     >
>     > Jim
>     >
>     >
>     >
>     >
>     >
>     > From: Andrew G. Malis <agmalis at gmail.com
>     <mailto:agmalis at gmail.com>>
>     > Sent: Monday, November 19, 2018 12:27 PM
>     > To: Henrik Levkowetz <henrik at levkowetz.com
>     <mailto:henrik at levkowetz.com>>
>     > Cc: ietf at augustcellars.com <mailto:ietf at augustcellars.com>;
>     xml2rfc-dev at ietf.org <mailto:xml2rfc-dev at 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 at levkowetz.com <mailto:henrik at levkowetz.com>
>     <mailto:henrik at levkowetz.com <mailto:henrik at levkowetz.com>> > wrote:
>     >
>     >
>     > On 2018-11-19 18:53, Jim Schaad wrote:
>     >>> -----Original Message-----
>     >>> From: Henrik Levkowetz <henrik at levkowetz.com
>     <mailto:henrik at levkowetz.com> <mailto:henrik at levkowetz.com
>     <mailto:henrik at levkowetz.com>> >
>     >>> Sent: Monday, November 19, 2018 9:32 AM
>     >>> To: Jim Schaad <ietf at augustcellars.com
>     <mailto:ietf at augustcellars.com> <mailto:ietf at augustcellars.com
>     <mailto:ietf at augustcellars.com>> >; xml2rfc-dev at ietf.org
>     <mailto:xml2rfc-dev at ietf.org> <mailto:xml2rfc-dev at ietf.org
>     <mailto:xml2rfc-dev at 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="tcp-header.svg" type="svg"/>
>     >>> >    <altArtwork src="tcp-header.txt" type="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="tcp-header.svg" type="svg"/>
>     >>>     <artwork src="tcp-header.txt" type="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 at ietf.org <mailto:xml2rfc-dev at ietf.org>
>     <mailto:xml2rfc-dev at ietf.org <mailto:xml2rfc-dev at ietf.org>>
>     > https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>     >
>     >
>
>
> _______________________________________________
> xml2rfc-dev mailing list
> xml2rfc-dev at ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20190207/d89bb18c/attachment.html>


More information about the rfc-interest mailing list