[rfc-i] Comments on draft-hoffman-xml2rfc-06

Elwyn Davies elwynd at folly.org.uk
Wed Apr 30 18:06:03 PDT 2014

Hi, Paul.

Some commenta on v06.

s1 or s1.1: Some words on the changeover to UTF-8 as (effectively)
default document encoding in line with the nonascii draft would probably
be useful. (And a pointer to s4).

s2.5/s2.5.2: I am not sure where you would ever use the "alt" attribute
since s2.5 envisages that the text content of the <artwork> is the 'alt'
text for any graphics file.  I suspect "alt" is now redundant.

s2.7, para 1: Suggest  s/document author./document's author, both for
the document itself and referenced documents./

s2.7.3, "initials": I guess the spacing stuff was too much like
formatting.  Are we still allowed optional space in the string? (If only
for backward compatibility!)

s2.10: <blockquote> doesn't seem to be a part of any content currently!

s2.10/2.10.2: I am *still* not convinced that the cite attribute should
be (always) a URI rather than a reference anchor.  What is the
justification? - I see there is supposed to be an example - and I don't
understand what shape the value of the cite would be for an existing

s2.16: I am still not sure where the specification of a "vague date"
would be provided since hard and limited specifications are provided for
day/month/year.  Could it be the content text if none of day/month/year
are provided (but illegal for the document itself)?

s2.16.2: I (still) don't see why the month can't be alternatively
specified as a month number (possibly easier for non mother tongie
authors).  Your argument that this was a style issue doesn't seem to
hold water, since the formatter can map from numbers just as easily if
that is what the style requires.

s2.18.2: s/anchror/anchor/

s2.21, <em>:  Would it be better to call this <emph> to match with
typical Tex usage (or is there some other prior art)?  Also does it
*have* to be italic and therefore the same as <i>?  Shouldn't this be
'typically italic' but left to the formatter to do it as it wants?
Accordingly should <i> be allowed content in <em(ph)> (and vice versa)?

s2.25: Why can't a figure be made up of any ordered combination of
<artwork>(s) and <sourcecode>(s)?  I can readily envisage something like
a flow chart with some added code that belongs together as a single
figure, and no real downsides.

s2.25.7: Needs to refer to the <titleelement> (or maybe <titleElement>)
as well as the "title" attribute.

s2.52: Does it *have* to be bold and therefore the same as <b>?
Shouldn't this be 'typically bold' but left to the formatter to do it as
it wants?  Accordingly should <b> be allowed content in <strong> (and
vice versa)?

s2.61: With <list> it was possible to preempt the formatter's choice of
symbol by using, e.g., style="format @" if the author felt the need to
control the label.  Should we provide (say) a "label" attribute to
override the default?

s2.65.1, para 3: s/this use used/this is used/

s4, para 2: needs rework now we have "ascii" all over the place.

App B, para 2: s/ares/are/

More information about the rfc-interest mailing list