Subject: [TOOLS-DEVELOPMENT] TextSubmissionConverter-03

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Aug 2014 16:07:41 -0500

In Toronto, Alice expressed some concerns about the effort needed to 
fix-up an automaton's attempt to parse an ascii submission.
Some brainstorming ensued, and I've tried to capture the essence here. 
Change-tracking is on.

RjS

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 13 Aug 2014 17:38:44 -0400

looks ok to me

fmi - is there any thought about dealing with nroff input?  (a few of us still do use nroff)

Scott

On Aug 13, 2014, at 5:07 PM, Robert Sparks <[email-masked]> wrote:

> In Toronto, Alice expressed some concerns about the effort needed to fix-up an automaton's attempt to parse an ascii submission.
> Some brainstorming ensued, and I've tried to capture the essence here. Change-tracking is on.
> 
> RjS
> 
> <TextSubmissionConverter-03.pdf><TextSubmissionConverter-03.docx>_______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Tony Hansen <[email-masked]>
Date: Wed, 13 Aug 2014 17:45:52 -0400

> Some brainstorming ensued, and I've tried to capture the essence here. 

You might want to add a comment somehow that the best first cut on a 
converter should probably be based on Henrik's rfcmarkup tool. It has 
the best heuristics around for identifying pieces of a text draft.

     Tony Hansen

---

From: Sandy Ginoza <[email-masked]>
Date: Wed, 13 Aug 2014 14:53:00 -0700

Hi Scott,

> fmi - is there any thought about dealing with nroff input?  (a few of us still do use nroff)

My understanding is that the .nroff would be used to create the .txt and we would use the “TextSubmissionConverter” to get the .xml file.

I’m sure someone will correct me if I’ve misunderstood.

Thanks,
Sandy

---

From: Sandy Ginoza <[email-masked]>
Date: Wed, 13 Aug 2014 15:33:19 -0700

Hi Robert,

Thanks for the opportunity to review.  I appreciate your attempt to address Alice’s concerns, but I don’t agree with this point: 

> A solution that allows the editor to assist with the conversion (perhaps graphically, or using an intermediate simplified language like markdown) will be preferred over one that requires the editor to edit the resulting XML directly. 
> 

Our editors are already familiar with XML and make updates routinely.  I would like to avoid having our staff learn another language just to get the conversion to do the right thing.  I have no doubt that our staff could learn the new language, but I’d hate to add another level of training for new staff as well; it would just make the training process that much tougher.

Thanks!
Sandy

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Aug 2014 17:37:52 -0500

On 8/13/14, 5:33 PM, Sandy Ginoza wrote:
> Hi Robert,
>
> Thanks for the opportunity to review.  I appreciate your attempt to 
> address Alice’s concerns, but I don’t agree with this point:
>
>> 0.
>>
>>     A solution that allows the editor to assist with the conversion
>>     (perhaps graphically, or using an intermediate simplified
>>     language like markdown) will be preferred over one that requires
>>     the editor to edit the resulting XML directly.
>>
>
> Our editors are already familiar with XML and make updates routinely. 
>  I would like to avoid having our staff learn another language just to 
> get the conversion to do the right thing.  I have no doubt that our 
> staff could learn the new language, but I’d hate to add another level 
> of training for new staff as well; it would just make the training 
> process that much tougher.
Ok - Would you prefer that I revert to what -02 said, or is there 
something different you would like the SoW to require?

RjS
>
> Thanks!
> Sandy
>
> On Aug 13, 2014, at 2:07 PM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> [email-masked] <mailto:[email-masked]>

---

From: Alice Russo <[email-masked]>
Date: Wed, 13 Aug 2014 15:57:04 -0700

Agree; I'm not convinced an intermediate language is advantageous.  In the future era, when the XML file is the canonical file, I see a benefit in the editor working directly on the XML file to make sure it contains what is desired/expected, as opposed to converting to an intermediate language (e.g., markdown), updating it in hopes of getting good XML, and then updating the XML.

I'm OK with the text from -02:

Rather, the application should produce a document that is well-formed, and  sufficiently close to correct that an editor can complete the conversion with minimal effort.  

Thanks,
Alice

On Aug 13, 2014, at 3:33 PM, Sandy Ginoza <[email-masked]> wrote:

>> 	• A solution that allows the editor to assist with the conversion (perhaps graphically, or using an intermediate simplified language like markdown) will be preferred over one that requires the editor to edit the resulting XML directly. 
>> 
> 
> _______________________________________________