Subject: [xml2rfc-dev] Alternate artwork vocabulary and post preptool

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Nov 2018 08:58:14 -0800

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.

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>

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.

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 19 Nov 2018 18:32:05 +0100

Hi Jim,

> the SVG which is embedded there.

That makes sense to me.

> 	<altArtwork src="tcp-header.txt" type="ascii-art"/>

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?

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>

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.

> This will be both easier to edit and easier to review for differences during

Ack.  I like it (but would prefer to avoid the parallel <altArtwork> element
without any enclosing (grouping) element).

Best,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Nov 2018 09:53:53 -0800

> -----Original Message-----
> From: Henrik Levkowetz <[email-masked]>
> Sent: Monday, November 19, 2018 9:32 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [xml2rfc-dev] Alternate artwork vocabulary and post preptool
> 
> Hi Jim,
> 
> > 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.
> 
> > 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>
> > 	<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.

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.

> 
> 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>

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.

> 
> 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.
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 19 Nov 2018 19:47:01 +0100

On 2018-11-19 18:53, Jim Schaad wrote:
> 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 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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 19 Nov 2018 15:26:43 -0500

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 <[email-masked]>
wrote:

> a bit
> contain text
> in a
> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Nov 2018 13:50:02 -0800

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.

Jim

From: Andrew G. Malis <[email-masked]> 
Sent: Monday, November 19, 2018 12:27 PM
To: Henrik Levkowetz <[email-masked]>
Cc: [email-masked]; [email-masked]
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 <[email-masked] <mailto:[email-masked]> > wrote:

On 2018-11-19 18:53, Jim Schaad wrote:
>> From: Henrik Levkowetz <[email-masked] <mailto:[email-masked]> >
>> To: Jim Schaad <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 

Aha, ok.

Understood.

        Henrik

_______________________________________________
xml2rfc-dev mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/xml2rfc-dev

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 19 Nov 2018 23:56:01 +0100

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 20 Nov 2018 08:10:52 -0500

Henrik,

That makes sense, thanks!

Cheers,
Andy

On Mon, Nov 19, 2018 at 5:56 PM Henrik Levkowetz <[email-masked]>
wrote:

> > 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
> >>> To: Jim Schaad <[email-masked] <mailto:[email-masked]>
> >; [email-masked] <mailto:[email-masked]>