Subject: [xml2rfc] attribute overlap on figure and artwork

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Nov 2013 12:01:39 +0100

Hi there,

the current DTD allows src/height/width both on <figure> and <artwork>. 
However, type is only allowed on <artwork>.

rfc2629.xslt only supports these attributes on <artwork> (and will emit 
warnings when they are used on <figure> soonish).

xml2rfc.tcl supports them on <figure> as well (and ignores the <artwork> 
child node when there's a src attribute on <figure>).

The "new" xml2rfc seems to ignore src & friends.

It's not clear to me why the DTD allows both -- would anybody be opposed 
to document them as "deprecated - use artwork" instead and potentially 
remove them in a future grammar?

Best regards, Julian

PS: a similar question could be asked for "align", but I'll do more 
tests first :-)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Nov 2013 08:35:43 -0800

On Nov 27, 2013, at 3:01 AM, Julian Reschke <[email-masked]> wrote:

> Hi there,
> 
> the current DTD allows src/height/width both on <figure> and <artwork>. However, type is only allowed on <artwork>.
> 
> rfc2629.xslt only supports these attributes on <artwork> (and will emit warnings when they are used on <figure> soonish).
> 
> xml2rfc.tcl supports them on <figure> as well (and ignores the <artwork> child node when there's a src attribute on <figure>).
> 
> It's not clear to me why the DTD allows both -- would anybody be opposed to document them as "deprecated - use artwork" instead and potentially remove them in a future grammar?

It seems fine to deprecate src/height/width in both <figure> and <artwork>. The edge case where an author wants to have external files seems not worth the overhead, given the ease of copy-and-paste (or even a trivial Perl/Python script that copies the artwork file into a marked place in the XML source).

> PS: a similar question could be asked for "align", but I'll do more tests first :-)

Alignment of artwork makes things pretty... and harder for a reader to copy-and-paste in a useful fashion.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 Nov 2013 11:00:56 -0600

> The "new" xml2rfc seems to ignore src & friends.

An src attribute should be useful; IMO it'd be best to keep it.  I'm not
sure that height and width are of any use.

> It's not clear to me why the DTD allows both -- would anybody be
> opposed to document them as "deprecated - use artwork" instead and
> potentially remove them in a future grammar?

Is the motivation only that the new xml2rfc doesn't [yet?] support
these?  Or that they are not necessary (height and width probably
aren't)?

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Nov 2013 18:58:28 +0100

> It seems fine to deprecate src/height/width in both <figure> and <artwork>. The edge case where an author wants to have external files seems not worth the overhead, given the ease of copy-and-paste…

Right now it's the only mechanism to include non line-art artwork, so 
I'll leave *one* mechanism in, even when it's not very useful for RFC 
production today (but don't forget RFC 5598...).

> Alignment of artwork makes things pretty... and harder for a reader to copy-and-paste in a useful fashion.

It's bad for code, but might be the right thing for diagrams.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Nov 2013 19:00:34 +0100

> sure that height and width are of any use.

Yes, it's bug in the new xmlrfc processor.

> these?  Or that they are not necessary (height and width probably

The motivation is that it's pointless to have them on both elements.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 Nov 2013 12:13:03 -0600

> Yes, it's bug in the new xmlrfc processor.

Oh good.  I thought you wanted to remove it altogether.

> The motivation is that it's pointless to have them on both elements.

Can <figure> contain multiple <artwork>s?  That might seem silly, but if
each artwork had an src attribute that might actually be useful.  In
that case I could see all these attributes (well, src anyways) being
useful in both elements:

<figure>
    <artwork src=".../part1"/>
    <artwork src=".../part2"/>
    <artwork src=".../part3"/>
</figure>

<figure src=".../artwork"/>

As for height and width, if they are merely informative then they are
useless; if they specify cropping, then they may have some marginal
utility, perhaps in conjunction with src and an attribute for "panning":

<figure>
    <artwork src=".../artwork" height="20", width="60"/>
    <artwork src=".../artwork" height="20", width="60" horizontal_pan="60"/>
    <artwork src=".../artwork" height="20", width="60" horizontal_pan="120"/>
</figure>

:)

Do I care enough for this?  No, so as long as src stays on one of these
elements I think I'm happy.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Nov 2013 19:20:40 +0100

> Can <figure> contain multiple <artwork>s?  That might seem silly, but if

Not right now, but I also think it would be good to group line art into 
chunks for better pagination.

>      <artwork src=".../part3"/>

Yes.

> <figure src=".../artwork"/>

But you can always put an <artwork> element into <figure>, so why 
support it on <figure> as well?

Essentially we have two ways to do the same thing, with the potential of 
conflicting information.

> elements I think I'm happy.

OK.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 27 Nov 2013 20:09:04 +0100

>>> On 2013-11-27 18:00, Nico Williams wrote:

<<snip>>

> Essentially we have two ways to do the same thing, with the potential of 

I agree.  And it seems to me that the proper place to place the src=
attribute would be <artwork/>.

>> elements I think I'm happy.

Best regards,

	Henrik

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 Nov 2013 13:29:33 -0600

> attribute would be <artwork/>.

+1

I could see <figure>s with no textual artwork, but instead non-text
artwork, like images.  However those should probably be included as an
<image> element.  We may need a way to select which to use for different
output formats:

<figure>
    <choice exp="$output_format">
        <when value="pdf">
            <image src=.../>
        </when>
        <default>
            <artwork src=.../>
        </default>
    </choice>
</figure>

or

<figure>
    <artwork exclude="pdf,html" src=.../>
    <image include="pdf,html" src=.../>
</figure>

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Nov 2013 13:16:22 -0800

On Nov 27, 2013, at 9:58 AM, Julian Reschke <[email-masked]> wrote:

> Right now it's the only mechanism to include non line-art artwork, so I'll leave *one* mechanism in, even when it's not very useful for RFC production today (but don't forget RFC 5598...).

If v2 is for today's drafts and RFCs, and it is not very useful for them, why leave it in?

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Nov 2013 23:22:50 +0100

> If v2 is for today's drafts and RFCs, and it is not very useful for them, why leave it in?

It's there (in the DTD), it's implemented (two independent 
implementations), and it's been used in practice.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Nov 2013 14:45:29 -0800

On Nov 27, 2013, at 2:22 PM, Julian Reschke <[email-masked]> wrote:

> It's there (in the DTD), it's implemented (two independent implementations), and it's been used in practice.

Ah, I didn't know that last bit. Good enough.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 30 Nov 2013 16:23:58 -0800

After looking at this, it is there for what I would consider to be a good
reason.

The align on the figure applies to the preamble, the artwork and the
postamble.  The align on the artwork would apply JUST to the artwork.

<figure align="right">
   <preamble>Text from the preamble</preamble>
   <artwork align="center">....</artwork>
   <postamble>.....</postamble>
</figure>

Jim

> -----Original Message-----
> From: xml2rfc [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, November 27, 2013 2:45 PM
> To: Julian Reschke
> Cc: xml2rfc
> Subject: Re: [xml2rfc] attribute overlap on figure and artwork
> 
I'll
> leave *one* mechanism in, even when it's not very useful for RFC
production
> today (but don't forget RFC 5598...).
> >>
> >> If v2 is for today's drafts and RFCs, and it is not very useful for
them, why
> leave it in?
implementations),
> and it's been used in practice.
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc