[rfc-i] Few nits in draft-hoffman-xml2rfc-07

Paul Hoffman 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/???

Yep.

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

Added.

> 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
> munged.
> 
> s6, para 2: s/formatter/processor/???

Yep

> 
> App B title: s/Format/Vocabulary (or maybe 'Representation' or
> 'Markup')/

"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
> 'markup')/

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.

--Paul Hoffman



More information about the rfc-interest mailing list