[rfc-i] Comments on draft-hoffman-xml2rfc-06
elwynd at folly.org.uk
Wed Apr 30 18:06:03 PDT 2014
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.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
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