Re: [xml2rfc-dev] <artset> feedback

[Julian Reschke <[e-mail]>]

On 09.05.2019 14:10, Julian Reschke wrote:
> On 09.05.2019 13:57, Henrik Levkowetz wrote:
>> 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?
>
>        artset =
>          element artset {
>            attribute xml:base { text }?,
>            attribute xml:lang { text }?,
>            attribute anchor { xsd:ID }?,
>            attribute pn { xsd:ID }?,
>            artwork+
>          }
>
> (I think)
>
>>> 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.
>
> If we just have "rich" and "text fallback", we can always capture that
> in HTML too (<img alt="..."> etc). It might not be visible by default,
> but it would at least be included.
>
>>> 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.
>
> +1 to always pick the first.
> ...

(if there is a type attribute)

Best regards, Julian