[xml2rfc-dev] <artset> feedback

[Julian Reschke <[e-mail]>]

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-


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.


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.


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.

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


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.

Best regards, Julian