Re: [Tools-discuss] draft submitted source versions

[Tom Pusateri <[e-mail]>]

> On Nov 27, 2019, at 12:08 PM, Henrik Levkowetz <[e-mail]> wrote:
> 
> 
> On 2019-11-27 17:48, Tom Pusateri wrote:
>> 
>> 
>>> On Nov 27, 2019, at 11:30 AM, Bob Hinden <[e-mail]> wrote:
>>> 
>>> Julian,
>>> 
>>>> On Nov 27, 2019, at 2:22 AM, Julian Reschke <[e-mail]> wrote:
>>>> 
>>>> On 27.11.2019 10:52, Michael Richardson wrote:
>>>>> 
>>>>> Tom Pusateri <[e-mail]> wrote:
>>>>>>> Tom Pusateri <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.
> 
> The datatracker draft submission page says:
> 
> "Either a plain-text document or a valid .xml file which can be processed by
>  the xml2rfc processor *must* be provided.
> 
>  If no .txt file is provided, one will be generated from the .xml file.
> 
>  Other file types are optional."
> 
> There are a number of valid options that can be used when processing .txt
> from an xml2rfc files, which will result in slightly different (and valid)
> .txt files.  Checking the result of converting submitted XML to .txt with
> submitted .txt is thus non-trivial.
> 
> Since there's no requirement to submit XML, people can submit any .txt they
> like.  And since we haven't seen a problem with XML / text mismatch, I don't
> think there is a problem to be solved here.  It's in authors' interest to
> provide good XML and text documents.
> 
> Any changes in the proposed direction seems to just make it harder for
> authors to submit drafts, and likely to encourage authors to *not* submit
> XML.

Sure, I get it.

I’m just thinking about good software engineering practices and tracking the source documents instead of the generated documents. I’m sure this will come up again when a real problem exists.

Thanks,
Tom