On 5/24/12 10:07 AM, "Paul Hoffman" <paul.hoffman at vpnc.org> wrote:
> From the above, it sounds like you believe that the submission requirement for
> RFCs would change from "whatever the RFC Editor can handle and turn into
> something they can use their tools on" to "marked up (including all metadata)
> HTML" or "XML like what is needed by xml2rfc, but with more metadata marking".
> Is that correct?
I bet the XML from xml2rfc has *most* of the metadata marking that's needed,
aside from some classification of example types (ASN.1 vs. ABNF, etc.),
alternate author name representation (which is in Julian's version, I
think). *IF* we want to deal with images (please let's don't open that can
of worms back up in this thread), then that would need to be added. There
are likely 5-6 other things that would need to be tweaked in the xml2rfc
format.
In this approach, the XML SHOULD be the only thing submitted, and (after a
cutoff date in the future) that would change from a SHOULD to a MUST.
I would want the HTML to always be generated, to be the canonical version
that we check for correctness, and wouldn't worry about images (if we do
them), unicode, or much else in the lineprinter format (until we decide that
it's not needed anymore). It would exist just for backward-compatibility
with existing tooling, and existing users who can't abide by anything
new-fangled.
I'd further like that HTML to retain as much semantic nature as possible, so
that one doesn't have to go back to the XML very often if at all.
I would expect that in that future, folks would eventually start asking why
they had to produce the oddball XML format as the input, since the only
version anyone ever uses is the HTML, and can I just submit the HTML?
I personally would prefer that we skip the intermediate step, but would live
with it if need be.
--
Joe Hildebrand