Re: [Tools-discuss] draft submitted source versions

[Tom Pusateri <[e-mail]>]

> On Nov 27, 2019, at 11:48 AM, Tom Pusateri <pusateri=[e-mail]> wrote:
> 
> 
> 
>> On Nov 27, 2019, at 11:30 AM, Bob Hinden <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Julian,
>> 
>>> On Nov 27, 2019, at 2:22 AM, Julian Reschke <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> On 27.11.2019 10:52, Michael Richardson wrote:
>>>> 
>>>> Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Tom Pusateri <pusateri=[e-mail] <mailto:pusateri=[e-mail]>> wrote:
>>>>>>> Is there anyway to tell if the TXT version was created from the
>>>>>>> submitted XML or was uploaded separately?
>>>>>> 
>>>>>>> If an XML version is submitted, is there any reason to allow DRAFT
>>>>>>> AUTHORS to submit alternate versions still?
>>>>>> 
>>>>>> If the XML won't format because the references.* files are AWOL, then
>>>>>> allowing the author to upload the TXT version lets them get around that.
>>>>>> 
>>>>>> This happened to me last week.
>>>> 
>>>>> Sure but then don’t accept the XML AND the TXT. If the XML is bad,
>>>>> reject it and accept the TXT.
>>>> 
>>>>> Otherwise you have two different source documents and there should be only one.
>>>> 
>>>> Yes, I see this problem, but I see a bigger problem of archival.
>>>> ...
>>> 
>>> Archiving XML with external dependencies is problematic anyway :-) (ok,
>>> archival not necessary, but assuming that the archived document can be
>>> used to re-create the same output files)
>> 
>> I have mixed feeling about this topic.
>> 
>> For submitting an Internet draft, I am not sure it matters very much.  We don’t currently require XML, the TXT is enough.  I personally always submit TXT and XML, but I assume the XML is not processed if I also submit a TXT file.   I would like to know if the two don’t match, but my main goal in submitting an ID is to get it published.  I suspect if it is common that the XML doesn’t produce a TXT file that matches, some folks would just stop submitting the XML, especially as it gets near an ID deadline.
>> 
>> RFCs are a very different matter.  There I assume we want the XML.   It would be a big problem if the XML didn’t produce the same TXT file, as it was the TXT file that people used to review the draft and approve it.
>> 
>> We might want to add a step (to IDnits?) where the XML and TXT are verified.   That would avoid problems later in the publicaiton process.
>> 
>> Bob
> 
> So I used to submit both XML and TXT and then I started thinking, if I am submitting XML, then why am I submitting TXT too, so I started only submitting XML and this works fine.
> 
> So that led me to wonder if the TXT was a by-product of the XML, then isn’t it causing confusion to submit them both and to suggest that if the XML is submitted and it checks out, then not to accept the TXT.
> 
> I think there should be a way to suggest that XML is desired and if received, sufficient, but not required.
> 
> Tom

I would even go a step further (than most of you) and say that authors should submit their source version. If that’s markdown using the kramdown-rfc2629 pre-processor, then submit markdown.

I know that might be a burden for the tools team but I think that the people who maintain those tools would pitch in.

Tom