Re: [xml2rfc-dev] <artset> feedback

[Julian Reschke <[e-mail]>]

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.

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

Let me disagree. The only case relevant for RFCs right now is SVG, and
that can be detected very easily be the processor without the presence
of a type attribute.

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

I believe it's much worse then before, thus I want to make sure people
are aware of it.

Best regards, Julian