[rfc-i] For v3: remove <format>?

Nico Williams nico at cryptonector.com
Thu Dec 26 21:38:35 PST 2013


On Thu, Dec 26, 2013 at 3:16 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> On Dec 26, 2013, at 11:38 AM, Nico Williams <nico at cryptonector.com> wrote:
>>>> This needs to be first-class.
>
> Sorry, I wasn't clear. Assuming that all the links we want will auto-generated from the <seriesInfo> element, why does <annotation> need to be first class?

seriesInfo works for Internet documents, not for non-IETF/IRTF documents.

>> For example... references to RFCs!  It'd be nice if the HTML rendering
>> of an RFC's references had clickable links to the canonical format
>> (today: .txt) of each referenced RFC and additional clickable links
>> for the HTML and PDF renderings of the referenced RFC.
>
> Wouldn't it be better to link to the RFC information page that has those links *plus* errata and additional metadata?

For RFCs, certainly, or almost anyways: I find superscript links to
alternate formats quite handy.  But even ignoring my personal
preference, a) it's nice to be able to extract this right from the doc
without having to go visit a potentially unstable resource, b) there
are what about not-{RFC, Internet-Draft, ...}?

>> The principle should be that as much meta-data as possible is
>> first-class, not buried in non-machine-parseable annotations.  I
>> shouldn't need to come up with an example for this principle to be
>> applied.  One should have to justify not following this principle.  It
>> isn't an arbitrary principle; it's the reason that we have an XML
>> input format in the first place, and it's a reason we're trying to
>> improve the schema.
>
> It's not clear that "three different ways to get this reference" is really metadata, particularly for references to other SDOs where one link might lead to an updatable version of the reference. My preference would be to make <seriesInfo> as robust as needed for the canonical XML, and then use the processors to generate the specific links we want for references.

*One* reference with *one* set of N formats.

That's just one way to reference the thing; that one could extract N
links is not relevant to how many ways there are to reference the
thing.

I'd rather you explain why that principle shouldn't apply or shouldn't
be adopted as a general guiding principle.

>> Even without a decent example like above, what if someone wanted to
>> analyze references, perhaps check to see what formats are most used at
>> various different times?  With first-class format meta-data they could
>> that with trivial XSLT for all RFCs for which XML source is available.
>
> That seems like optimizing for a far edge case, particularly because that researcher could just look in the XML, not the HTML.

That's the thing: how will the XML denote links to alternate formats?
If there's no way to do that, then the researcher couldn't "just look
in the XML" (i.e., not with XPath/XSLT).

Nico
--


More information about the rfc-interest mailing list