[xml2rfc] 1.30pre1 patch + pending issues

[henrik at levkowetz.com (Henrik Levkowetz)]

on 2005-04-21 9:27 pm Paul Hoffman said the following:
> At 12:17 PM -0700 4/21/05, Larry Masinter wrote:
>>  > I disagree. Remember, the person writing the draft should in fact
>>>  read what the tool outputs and can even change it if they feel like
>>>  it. Regardless of which of the ipr=foo options they choose, they need
>>>  to read what the tool outputs.
>>
>>But
>>http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
>>proposes allowing Internet Draft authors the option of uploading
>>only the XML, and having the text automatically generated by
>>the submission tool.
> 
> Then that is a bug in that draft. There are plenty of things that one 
> can do to one's XML that would make parts of a draft difficult to 
> read. In this case, there are things that can cause you to attest to 
> things you don't believe.

Please be specific.  

The xml2rfc version which was current at the time the draft was written
(and submitted) did not support ipr="fullBCP78", so that was not an issue
then, and will only be an issue if xml2rfc takes in support for it, in
which case we may have to disallow use of ipr="fullBCP78" in submitted
XML. (Which is a roundabout way of saying that it might be a bad idea
to have that functionality in xml2rfc...)

The draft also excludes xml format submissions which contain include PIs
which cannot be resolved by 'standard' reference libraries - Marshall's
bibxml collection being the only recognised one currently.  Such sources
has to be expanded by the author before submission.

Is there something else we need to disallow?  We'll fix it if we
know about it, but as of now, until ipr="fullBCP78" is accepted as part
of xml2rfc, or there are more specifics given about other constructs we
need to exclude, I don't see that we have a bug in the submission tool
draft.  (But please don't interpret this as us being unwilling to listen
to input - that's _not_ what I'm saying.)

> Anything that "submits" an Internet Draft should allow the submitter 
> to review it in the form it will be published.

And indeed the submission tool draft specifies that a preview of the
submission should be generated and presented to the submitter.

	Henrik
>From carl at media.org  Thu Apr 21 14:57:45 2005
From: carl at media.org (Carl Malamud)
Date: Thu Apr 21 13:58:29 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

I think Paul's point, if I may attempt to translate, is that the tool
should consist of:

1. please select an xml file to process
2. [crunch]
3. here is the ascii for you to look over briefly
4. [hit the submit button to finalize this and submit your draft]

(or)

3a. whoops, our parser detected something bad, please try again

Carl

[ Charset ISO-8859-1 unsupported, converting... ]
> on 2005-04-21 9:27 pm Paul Hoffman said the following:
> > At 12:17 PM -0700 4/21/05, Larry Masinter wrote:
> >>  > I disagree. Remember, the person writing the draft should in fact
> >>>  read what the tool outputs and can even change it if they feel like
> >>>  it. Regardless of which of the ipr=foo options they choose, they need
> >>>  to read what the tool outputs.
> >>
> >>But
> >>http://www.ietf.org/internet-drafts/draft-ietf-tools-draft-submission-08.txt
> >>proposes allowing Internet Draft authors the option of uploading
> >>only the XML, and having the text automatically generated by
> >>the submission tool.
> > 
> > Then that is a bug in that draft. There are plenty of things that one 
> > can do to one's XML that would make parts of a draft difficult to 
> > read. In this case, there are things that can cause you to attest to 
> > things you don't believe.
> 
> Please be specific.  
> 
> The xml2rfc version which was current at the time the draft was written
> (and submitted) did not support ipr="fullBCP78", so that was not an issue
> then, and will only be an issue if xml2rfc takes in support for it, in
> which case we may have to disallow use of ipr="fullBCP78" in submitted
> XML. (Which is a roundabout way of saying that it might be a bad idea
> to have that functionality in xml2rfc...)
> 
> The draft also excludes xml format submissions which contain include PIs
> which cannot be resolved by 'standard' reference libraries - Marshall's
> bibxml collection being the only recognised one currently.  Such sources
> has to be expanded by the author before submission.
> 
> Is there something else we need to disallow?  We'll fix it if we
> know about it, but as of now, until ipr="fullBCP78" is accepted as part
> of xml2rfc, or there are more specifics given about other constructs we
> need to exclude, I don't see that we have a bug in the submission tool
> draft.  (But please don't interpret this as us being unwilling to listen
> to input - that's _not_ what I'm saying.)
> 
> > Anything that "submits" an Internet Draft should allow the submitter 
> > to review it in the form it will be published.
> 
> And indeed the submission tool draft specifies that a preview of the
> submission should be generated and presented to the submitter.
> 
> 	Henrik
> _______________________________________________
> xml2rfc mailing list
> [e-mail]
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/xml2rfc
> 
>From fenner at gmail.com  Thu Apr 21 15:21:57 2005
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr 21 14:22:05 2005
Subject: [xml2rfc] 1.30pre1 patch + pending issues
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	 <[e-mail]>
Message-ID: <[e-mail]>

On 4/21/05, Carl Malamud <[e-mail]> wrote:
> I think Paul's point, if I may attempt to translate, is that the tool
> should consist of:
> 
> 1. please select an xml file to process
> 2. [crunch]
> 3. here is the ascii for you to look over briefly
> 4. [hit the submit button to finalize this and submit your draft]
> 
> (or)
> 
> 3a. whoops, our parser detected something bad, please try again

I think Henrik's point is that sounds exactly like what's currently specified.

...[after uploading just an .xml file, and letting the tool process
it, you get the Check page so that you can check on the results of the
conversion and metadata extraction.  Among other things,]
   The Check page provides a preview of the draft plain text format 
   (R31/a), with a link to see how the entire draft (with all its
   formats) would look like if posted (R82/b).  Hint: the Check page
   preview should be sufficiently long to let authors detect obvious
   draft mismatch or misinterpretation errors but short enough to avoid
   dominating the page.  Displaying the first line of the draft through
   the last line of the abstract may be sufficient.
...


  Bill