Re: [xml2rfc-dev] <artset> feedback

[Henrik Levkowetz <[e-mail]>]

Hi Julian,

On 2019-05-09 13:24, Julian Reschke wrote:
> Hi there,
> 
> see below for some feedback on <artset>, as currently described in 
> <https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-08#section-3.1.1>.
> 
> I have worked on an implementation in rfc2629.xslt (which should be 
> fairly complete), and have my own set of tests at 
> <https://greenbytes.de/tech/webdav/rfc2629xslt/v3test.xml#artset>. So 
> please read this as implementer's *practical* feedback.
> 
> In general I found this change to be very disruptive, because it affects 
> all code that deals with <artwork>, and everything related to it 
> (numbering, references, etc). A simpler approach (as proposed back then) 
> IMHO would be far better.
> 
> That said, here are the details:
> 
> 
> 1) The grammar allows <artset> to be empty
> 
> This makes things really hard. How is an empty <artset> element expected 
> to be handled? Does it contribute to the counting of paragraphs? Can it 
> be target of an <xref>? These things of course could be defined, but it 
> would be much simpler to require at least one <artwork> child element-

Good point.  What would be your proposed grammar change to address this?

> 2) anchor propagation and <xref>
> 
> "The first anchor on an <artwork> element within an <artset> element 
> will be promoted to the <artset> element if it has none; apart from 
> that, anchors on <artwork> elements within an <artset> element will be 
> removed by the preptool."
> 
> I understand that this is supposed to make the author's life easier - an 
> existing <artwork> element can be moved into a new <artset> container 
> without modification.
> 
> However, it causes lots of edge cases, such as: what happens if I <xref> 
> an <artwork> element that does not appear in the rendered output? I 
> *assume* the intention is to say that the anchor propagation applies (1) 
> not only at the preptool stage, and (2) applies *both* to the <artwork> 
> elements and all <xref>s referencing them - but the spec would need to 
> say way more about that.

Ok.

> 3) Invisible content
> 
> Having multiple <artwork> alternatives can lead to content being present 
> in the canonical XML, but not to appear in the rendered output. I can 
> see that this is a problem with textual fallback content already, but 
> allowing any number of altenative <artwork> elements in the canonical 
> XML makes this a much more serious problem.

I don't see this -- the essential problem is the same whether the number
of alternatives are 2 or more than 2.  And that is built into the idea
that the XML should be able to provide richer content for HTML than for
text; I don't see any way around this.

> 4) Processing model
> 
> "This would let the renderer pick the most appropriate <artwork> 
> instance for its format from the alternatives present within an <artset> 
> element, based on the "type" attribute of each enclosed <artwork> 
> element.If more than one <artwork> element is found within an <artset> 
> element, with the same "type" attribute, the renderer could select the 
> first one, or possibly choose between the alternative instances based on 
> the output format and some quality of the alternative instances that 
> made one more suitable than the other for that particular format, such 
> as size, aspect ratio, or whatnot."
> 
> "Implementation:  Xml2rfc as of version 2.19.0 implements this, with a 
> preference list when rendering to HTML and PDF of ( "svg", "binary-art", 
> "ascii-art" ), while the text renderer uses the list
>        ( "ascii-art", ) -- i.e., one entry only."
> 
> So there is no precise processing model, due to the fact that we can't 
> predict what kind of alternative formats will come up. The description 
> of the *actual* model is specific to a certain version of one 
> implementation.

The serious fussiness here comes from 

  1) not prescribing whether the first or some other <artwork> should be
     chosen when there are multiple instances with the same type.
     For this, I propose that we codify that the first is always chosen,
     or alternatively, make it an error to have more than one of each type.

  2) having implementation-specific preference lists.  We could codify this
     more strictly too.  Would the xml2rfc settings work for you here?

> In addition, this depends on the "type" attribute which as per RFC 7991 
> is sort of advisory only (see 
> <https://greenbytes.de/tech/webdav/rfc7991.html#element.artwork.attribute.type>).
> 
> I believe it would be better (and more author friendly) to actually 
> inspect the contents of the <artwork>, and decide based on that (that's 
> what I'm currently doing in rfc2629.xslt).

We've had this discussion before, and disagree.  I maintain that an explicit
type is better than an implicit type.  An implicit type leads to _huge_
difficulties in specifying exactly how the inspection is done and how
the result is interpreted.

> I have spent a significant amount of time to implement this, but I'd 
> still prefer to throw this all away and make a less-intrusive extension 
> instead.
> 
> That being said, point 3) above really needs to be discussed in the 
> context of how the canonical form and the default rendering relate to 
> each other.

And that's the issue that is inherent also in the RFC 7991 schema, since it
permits 2 different artworks, only one of which will be shown in the
rendered form.  Nothing new here.  I'm fine with discussing the issue, but
don't make it out as something introduced with <artset>.


Regards,

	Henrik