Subject: Re: [TOOLS-DEVELOPMENT] PublicationFormatter-01

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 06 Oct 2014 06:49:50 -0700

Did anyone else have comments to offer on this SoW draft, or any
thoughts on my input below?

Thanks,
Heather

On 9/10/14 9:06 AM, Heather Flanagan (RFC Series Editor) wrote:
>
> I've included my comments in the Word doc (attached) but in case any
of them require group discussion, I've also called them out here.
>
> 1. In Deliverables/Tasks, bullet four is not complete.  Do you mean to
say "through a web interface"?
>
> 2. For the first TODO, the example draft that Julian and Paul have
signed up for is more a series of examples on how specific components
would be handled in v2 vs v3.  So probably the existing test draft,
updated to use the v3 grammar and reviewed by the design team makes the
most sense.
>
> 3. Regarding "The application suite will accept input using
either...", would saying "both" instead of "either" be clearer?  One
might interpret the "either" as "either v2 or v3, but not necessarily both".
>
> 4. For the second TODO: I thought PublicationFormatter was in part the
grammar converter, seeing as how it includes creating a v3 document from
a v2 document?
>
> On 8/13/14, 3:03 PM, Robert Sparks wrote:
> > This document is still early. The previous version didn't get a lot
of feedback (outside the peripheral discussion of folding the v2 to v3
converter into it).
> > The below questions are still outstanding. Please comment on them.
>
> > If you have a "This document is going to have to say X before it's
done", please call X out.
> > If you think it's enough for work to start from as soon as we fill
in the TODOs that are already there, please say that too.
>
> > RjS
>
> > On 6/30/14, 4:07 PM, Robert Sparks wrote:
> >> Ok - since the only feedback I got was to stay generic, the first
draft does that and is attached.
> >> It is a very small start, but I hope to get enough conversation
going before we get to Toronto that we
> >> can knock of bigger things in the hallway if we need to.Please
review and comment this week if
> >> you can. Some specific questions about what the next layer of
information here should be:
> >>
> >> * Do you think the referenced documents supply enough information
about the
> >>    target formats that the folks we would ask to do development
would know what
> >>    to produce?
> >>
> >> * What other high level user experience requirements do we
incorporate here? For instance, do we
> >> rely on the separate rfclint to tell people what's wrong with their
document if it's not correct enough
> >> to convert? Should this application invoke that directly (with an
evolution of xml2rfc, that's what
> >> would happen naturally).
> >>
> >> RjS
> >>
> >> On 6/25/14, 11:56 AM, Robert Sparks wrote:
> >>>
> >>> On 6/25/14, 11:40 AM, Julian Reschke wrote:
> >>>> On 2014-06-25 18:30, Robert Sparks wrote:
> >>>>> All -
> >>>>>
> >>>>> I'm starting to build the first version of the SoW for tools
that would
> >>>>> make the first set of presentation formats from the canonical
XML for an
> >>>>> RFC.
> >>>>> The requirements will include that people can run the conversion on
> >>>>> their own machine on v3 formatted internet drafts.
> >>>>
> >>>> Just to make sure: this includes the parts that are deprecated as
well, right?
> >>> yes
> >>>>
> >>>>> Should we write this in generic terms like "one or more applications
> >>>>> that produce the following outputs"
> >>>>> or write it directly in terms of extending the capabilities of
xml2rfc?
> >>>>
> >>>> As in the v2 python code, I assume?
> >>> yes
> >>>>
> >>>>> If we produce something written the first way, I fully expect
extending
> >>>>> the capabilities of xml2rfc to be a strong contending proposal.
Do we
> >>>>> anticipate any others?
> >>>>
> >>>> I don't believe we should rule them out.
> >>>>
> >>>> Best regards, Julian
> >>>>
> >>>
> >>> _______________________________________________
> >>> TOOLS-DEVELOPMENT mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/tools-development
> >>
> >>
> >>
> >> _______________________________________________
> >> TOOLS-DEVELOPMENT mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/tools-development
>
>
>
> > _______________________________________________
> > TOOLS-DEVELOPMENT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tools-development
>
>
>
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Oct 2014 11:16:21 -0500

(The difference between 10/30 and 9/10 makes me cringe - I'm really sorry)

On 9/10/14 11:06 AM, Heather Flanagan (RFC Series Editor) wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
something similar. Fixed.
> updated to use the v3 grammar and reviewed by the design team makes 
> the most sense.
Yes (and OBE). I'm pointing to Joe's example input now. We need to build 
a version of the other test document I point to (from the v2 codebase) 
that is v3 specific. That will be more than just running it through the 
v2 to v3 converter - it needs to have things added to exercise the new 
v3 things.
> might interpret the "either" as "either v2 or v3, but not necessarily 
I tried several things here, and ended up leaving the text alone.
The problem with the suggestion is it adds the potential confusion that 
a given document might have both v3 and v2 stuff in it, which is not 
something we will allow. I think the context makes it clear that a 
solution that only implements one of the grammars is unacceptable.
> grammar converter, seeing as how it includes creating a v3 document 
> from a v2 document?
Yes, this tool is expected to be the converter, and the text in front of 
that TODO was intended to imply that. Please check the next version to 
see if it's clearer there. From discussions with Tony, he's suggesting 
treating his implementation as a prototype that this project will 
reimplement.
> > This document is still early. The previous version didn't get a lot of feedback (outside the 
> peripheral discussion of folding the v2 to v3 converter into it).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJUEHcVAAoJEER/xjINbZoGY/4IALqHE/NOJe8NamQFQdL3s/cS
> AJ5aiLsQtZH0rmVk2NrEdUx+/JwiyrVOEGxIrK1Ir9IyanCuzyinz5IJNntT4+t7
> Oi06Vy9gQGAE07V5ciNIeSXPzqd3YPISIaluh0t2Xweja45uIm39/jEZrzkw8SBK
> K4ulCKjbO4C99FRY29ZdorX5PUhYanu+wJoo2L+Xd+92N0RbO74ERGBig6aw2MmR
> CkBDKr3hjI7bx43dYde0cXU9wWfWNJm0AE/btJGh9hyvPezu4TJO9meXoZ0Lu+xc
> biLu981sgZgNsdyLmY20qmlKVGgNqm2xr0M5SktbMQUj1fu1bmAZmJLtYjgSfD0=
> =3zhE
> -----END PGP SIGNATURE-----
>
>
>