[rfc-i] Few nits in draft-hoffman-xml2rfc-07
paul.hoffman at vpnc.org
Thu May 8 10:28:38 PDT 2014
On May 8, 2014, at 8:53 AM, Elwyn Davies <elwynd at folly.org.uk> wrote:
> s1.2.4, 1st bullet: s/format/representation/
In this case, it is actually the format. The v2 document says:
Although the current RFC format does not allow non-ASCII Unicode
characters ([UNICODE]), some of them can be used to enforce certain
behaviors of formatters.
> s2.16, para 2: s/formatter/processor/???
> s2.17 (and subsections) <date>: I am not convinced by the idea of
> having alternative free-format options for month and year attributes.
> Its messy - and if we *do* go this way the definitions of the attributes
> have to be changed as they don't match with the 'vague' case. I'd still
> go with using the content for the vague case and leave the attributes
> for the precise case.
As Julian says, this is a request to change both the v2 and v3 processors. Personally, I don't think it is a good suggestion. For example, there are academic journals that are quarterly, so being able to say "Spring" instead of "April" will give a better reference.
> s2.28: My inclination would be to keep the 'smaller' items together at
> the front - so put the <alternateURI>(s) after <keyword>(s) rather than
> at the end, but no big deal.
Instead of picking colors for the bikeshed, we are now choosing the relative font sizes for the sign on the door. :-)
> s2.32 <li>/s2.36 <ol>/s2.36.3, start attr: Ought to be explicit about
> how we move along the list of style characters or generate the label
> from the (internal) counter at each new <li>. Are negative values
> allowed for 'start'? If not we should say so.
> s2.47.10 outputType attribute: I think this is a usefule idea but I also
> think a better name for this would be 'documentType' which avoids
> confusion with the 'output representation' (and all document types can
> appear in some or all output representations). Other options are being
> discussed I see.
At this point, I prefer documentType over submissionType, and both over outputType. However, I'm still liking the idea of getting rid of it again and just basing it on heuristics of docName.
> App C.1: I think there may be need/requirement for at least one XML
> comment block at the start of the document but this is a discussion for
> a different place.
Do start that as a different thread, yes.
> *** The remainder are a few cases of format that might need to be
> s6, para 2: s/formatter/processor/???
> App B title: s/Format/Vocabulary (or maybe 'Representation' or
"Format" is more appropriate here because it is more than just the vocabulary: it is also the prose rules that go along with the vocabulary. Format seems to be the common term for XML vocabulary + rules.
> App B, para 3: s/format/syntax/
No, for the same reason. A processor might check, for example, that the value in the number attribute of an <ol> element is not a string representation of a negative integer. That's a format rule, not a syntax rule.
> App B, last para: s/format/input representation (or maybe 'markup')/
No, same reasoning.
> App B.1, several places: s/format/input representation(or maybe
One place, and I'll use "syntax" here because it really is just a syntactic issue.
> App C title and App D title: s/Format/Representations/
These are definitely input format, not representation.
More information about the rfc-interest