OASIS Virtual I/O Device (VIRTIO) TC

Per the TC's submission request [1], please find the attached starter document for:  Virtual I/O Device (VIRTIO) Version 1.0 WP-abbrev: virtio When the TC first votes [5] to publish this Work Product in the OASIS Library, we expect it to be published at: http://docs.oasis-open.org/virtio/virtio/v1.0/csd01/virtio-v1.0-csd01.odt Please let me know if anything here fails to meet your expectations. Further revisions to this Work Product must be maintained in Working Drafts, following procedures detailed in the OASIS TC Administration How-to Guide [2]. Working Drafts should be made available by uploading the document(s) to the TC's Kavi document repository, or (provisionally/temporarily) to the TC's Subversion (SVN) repository, if SVN has been activated for your TC [3].  TCs are encouraged to use ZIP packaging when the WD releases contain multiple files (and directories). For each WD revision, you will need to: 1) increment the Working Draft revision (number) from 01 to 02, 03, 04 etc., as successive Working Drafts are produced; the revision number needs to be updated at the top of the document in the stage identifier (Working Draft ##) and in the document identifier within the page footer. 2) supply the relevant publication/release/upload date for each successive Working Draft instance, using the  prescribed date format: DD Month YYYY; the date needs to be updated at the top of the document (just below the stage identifier, Working Draft ##) and in the page footer. 3) provide suitable text for a document Abstract, updating this summary with successive revisions to provide an accurate description of the subject matter, goals, scope, etc. 4) keep the Acknowledgments (Appendix A) and Revision History (Appendix C) up-to-date with each WD revision. 5) consult the OASIS Naming Directives document when creating new artifacts that may be part of the Work Product (e.g., image files, XML schemas), observing the rules for name characters in files and proposed directories, and for proposed URIs/namespaces [4]. When the TC votes [5] to approve a Working Draft as a Committee Draft (CSD or CND), the Chair or other designated person must submit a "Committee Specification Draft Creation and Upload Request" accessible on the TC Administration Requests Page [6].   Upon receipt of this form, the TC Administrator will QC and process the Work Product for official publication in the OASIS Library ( http://docs.oasis-open.org/ ) as a Committee Draft, including addition of the requisite cover page metadata and other boilerplate information. =========== References: [1] https://tools.oasis-open.org/issues/browse/TCADMIN-1514 [2] Developing Committee Specifications and Notes     https://www.oasis-open.org/resources/tcadmin/developing-committee-specifications-and-notes     Starting a Working Draft     https://www.oasis-open.org/resources/tcadmin/starting-a-working-draft [3] SVN Version control, via Tools     https://tools.oasis-open.org/ [4] OASIS Naming Directives     http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html [5] Approval of a WD as a CD (CSD or CND)     https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft     https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft [6] TC Administration Requests Page, see Committee Specification Draft Creation / Upload Request     https://www.oasis-open.org/resources/tc-admin-requests Best wishes, Paul -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Hi all, Starter document should be attached this time. ... Great to see the TC's first Work Product (publication) underway! On Fri, Nov 8, 2013 at 4:19 PM, Paul Knight < paul.knight@oasis-open.org > wrote: Per the TC's submission request [1], please find the attached starter document for:  Virtual I/O Device (VIRTIO) Version 1.0 WP-abbrev: virtio When the TC first votes [5] to publish this Work Product in the OASIS Library, we expect it to be published at: http://docs.oasis-open.org/virtio/virtio/v1.0/csd01/virtio-v1.0-csd01.odt Please let me know if anything here fails to meet your expectations. Further revisions to this Work Product must be maintained in Working Drafts, following procedures detailed in the OASIS TC Administration How-to Guide [2]. Working Drafts should be made available by uploading the document(s) to the TC's Kavi document repository, or (provisionally/temporarily) to the TC's Subversion (SVN) repository, if SVN has been activated for your TC [3].  TCs are encouraged to use ZIP packaging when the WD releases contain multiple files (and directories). For each WD revision, you will need to: 1) increment the Working Draft revision (number) from 01 to 02, 03, 04 etc., as successive Working Drafts are produced; the revision number needs to be updated at the top of the document in the stage identifier (Working Draft ##) and in the document identifier within the page footer. 2) supply the relevant publication/release/upload date for each successive Working Draft instance, using the  prescribed date format: DD Month YYYY; the date needs to be updated at the top of the document (just below the stage identifier, Working Draft ##) and in the page footer. 3) provide suitable text for a document Abstract, updating this summary with successive revisions to provide an accurate description of the subject matter, goals, scope, etc. 4) keep the Acknowledgments (Appendix A) and Revision History (Appendix C) up-to-date with each WD revision. 5) consult the OASIS Naming Directives document when creating new artifacts that may be part of the Work Product (e.g., image files, XML schemas), observing the rules for name characters in files and proposed directories, and for proposed URIs/namespaces [4]. When the TC votes [5] to approve a Working Draft as a Committee Draft (CSD or CND), the Chair or other designated person must submit a "Committee Specification Draft Creation and Upload Request" accessible on the TC Administration Requests Page [6].   Upon receipt of this form, the TC Administrator will QC and process the Work Product for official publication in the OASIS Library ( http://docs.oasis-open.org/ ) as a Committee Draft, including addition of the requisite cover page metadata and other boilerplate information. =========== References: [1] https://tools.oasis-open.org/issues/browse/TCADMIN-1514 [2] Developing Committee Specifications and Notes     https://www.oasis-open.org/resources/tcadmin/developing-committee-specifications-and-notes     Starting a Working Draft     https://www.oasis-open.org/resources/tcadmin/starting-a-working-draft [3] SVN Version control, via Tools     https://tools.oasis-open.org/ [4] OASIS Naming Directives     http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html [5] Approval of a WD as a CD (CSD or CND)     https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft     https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft [6] TC Administration Requests Page, see Committee Specification Draft Creation / Upload Request     https://www.oasis-open.org/resources/tc-admin-requests Best wishes, Paul -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Paul Knight <paul.knight@oasis-open.org> writes: > Per the TC's submission request [1], please find the attached starter > document for: > Virtual I/O Device (VIRTIO) Version 1.0 > WP-abbrev: virtio Hi Paul, As the editors have asked, is it possible for us to do this in TeX instead? I erroneously assumed that OO would be easiest. I note that CMIS seems to have taken this path. In that case, should we prepare the TeX draft ourselves using the OO document you supplied (and cribbing the CMIS 1.1 source if required), or are there requirements at your end? Sorry for the hassle, Rusty.

I imported latex templates from the CMIS specifications and changed s/CMIS/VIRTIO/ everywhere. The result is very close to one produced by exporting from the ODF we were supplied, with the exception of the TOC formatting, where section numbers are in blue instead of black, and major sections don't have dots leading to page numbers. I'm guessing this isn't very important, someone with more latex knowledge can try to figure this out. Generating html doesn't actually work for me. It doesn't work for me for CMIS either, so it's probably just an issue with my local latex setup. I'm not sure we need html output at all. The PDF output is attached. For the curious, the source can temporarily be seen in my private repository here: git://git.kernel.org/pub/scm/virt/kvm/mst/virtio-text.git latex If that's OK with everyone, I can commit the result and we can convert from text to this template. -- MST Attachment: virtio-v1.0-csd01.pdf Description: Adobe PDF document

"Michael S. Tsirkin" <mst@redhat.com> writes: > If that's OK with everyone, I can commit > the result and we can convert from text to this template. OK, please do. This would be ideal for an SVN branch, but I'm not sure how to do that with git svn. If you figure it out, please do, otherwise we'll just do it in the main SVN branch. Cheers, Rusty.

Hi Michael, hi Rusty,  Let me jump in and help out here a bit.  By using latex as your source, you will be taking responsibility for generating the editable source, HTML and PDF editions that TC Admin normally prepares for the Technical Committees from odf or doc working draft files.  So you will need to work with us to establish all the proper metadata is there and in the proper format. We worked with the CMIS TC to get this all down right & will gladly work with you to make sure everything is in the proper shape and form.  I haven't looked at the pdf attached yet - I'll do so today. Paul and I can prep a list of metadata for you.  What kind of timeframe are you looking for? When do you want the TC to be able to vote to approve the draft?  Thanks,  /chet  On Sun, Nov 17, 2013 at 8:18 AM, Michael S. Tsirkin < mst@redhat.com > wrote: I imported latex templates from the CMIS specifications and changed s/CMIS/VIRTIO/ everywhere. The result is very close to one produced by exporting from the ODF we were supplied, with the exception of the TOC formatting, where section numbers are in blue instead of black, and major sections don't have dots leading to page numbers. I'm guessing this isn't very important, someone with more latex knowledge can try to figure this out. Generating html doesn't actually work for me. It doesn't work for me for CMIS either, so it's probably just an issue with my local latex setup. I'm not sure we need html output at all. The PDF output is attached. For the curious, the source can temporarily be seen in my private repository here: git:// git.kernel.org/pub/scm/virt/kvm/mst/virtio-text.git latex If that's OK with everyone, I can commit the result and we can convert from text to this template. -- MST --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

On Mon, Nov 18, 2013 at 09:41:43AM -0500, Chet Ensign wrote: > Hi Michael, hi Rusty,  > > Let me jump in and help out here a bit.  > > By using latex as your source, you will be taking responsibility for generating > the editable source, HTML and PDF editions that TC Admin normally prepares for > the Technical Committees from odf or doc working draft files.  > > So you will need to work with us to establish all the proper metadata is there > and in the proper format. We worked with the CMIS TC to get this all down right > & will gladly work with you to make sure everything is in the proper shape and > form.  > > I haven't looked at the pdf attached yet - I'll do so today. Paul and I can > prep a list of metadata for you.  > > What kind of timeframe are you looking for? When do you want the TC to be able > to vote to approve the draft?  > > Thanks,  > > /chet  > I think the plan was Dec 3. The text is approved by now. Of course we still actually need to prepare it in the correct format and give people time to review. > On Sun, Nov 17, 2013 at 8:18 AM, Michael S. Tsirkin <mst@redhat.com> wrote: > > I imported latex templates from the CMIS specifications > and changed s/CMIS/VIRTIO/ everywhere. > > The result is very close to one produced by exporting from the > ODF we were supplied, with the exception of the TOC formatting, > where section numbers are in blue instead of black, and major > sections don't have dots leading to page numbers. > > I'm guessing this isn't very important, someone with more latex > knowledge can try to figure this out. > > Generating html doesn't actually work for me. > It doesn't work for me for CMIS either, so > it's probably just an issue with my local latex setup. > > I'm not sure we need html output at all. > > The PDF output is attached. > > For the curious, the source can temporarily be seen in my private > repository here: > git://git.kernel.org/pub/scm/virt/kvm/mst/virtio-text.git latex > > If that's OK with everyone, I can commit > the result and we can convert from text to this template. > > -- > MST > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > -- > > /chet  > ---------------- > Chet Ensign > Director of Standards Development and TC Administration  > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-996-2298 > Mobile: +1 201-341-1393  > > Check your work using the Support Request Submission Checklist at http:// > www.oasis-open.org/committees/download.php/47248/ > tc-admin-submission-checklist.html  > > TC Administration information and support is available at http:// > www.oasis-open.org/resources/tcadmin > > Follow OASIS on: > LinkedIn:     http://linkd.in/OASISopen > Twitter:         http://twitter.com/OASISopen > Facebook:   http://facebook.com/oasis.open

Great, thanks for that. Paul and I will get feedback to you on what we see in the PDF in the next day or two. If you could also generate an HTML copy and send it to us, that would be helpful too.  Best,  /chet On Mon, Nov 18, 2013 at 9:54 AM, Michael S. Tsirkin < mst@redhat.com > wrote: On Mon, Nov 18, 2013 at 09:41:43AM -0500, Chet Ensign wrote: > Hi Michael, hi Rusty,  > > Let me jump in and help out here a bit.  > > By using latex as your source, you will be taking responsibility for generating > the editable source, HTML and PDF editions that TC Admin normally prepares for > the Technical Committees from odf or doc working draft files.  > > So you will need to work with us to establish all the proper metadata is there > and in the proper format. We worked with the CMIS TC to get this all down right > & will gladly work with you to make sure everything is in the proper shape and > form.  > > I haven't looked at the pdf attached yet - I'll do so today. Paul and I can > prep a list of metadata for you.  > > What kind of timeframe are you looking for? When do you want the TC to be able > to vote to approve the draft?  > > Thanks,  > > /chet  > I think the plan was Dec 3.  The text is approved by now.  Of course we still actually need to prepare it in the correct format and give people time to review. > On Sun, Nov 17, 2013 at 8:18 AM, Michael S. Tsirkin < mst@redhat.com > wrote: > >     I imported latex templates from the CMIS specifications >     and changed s/CMIS/VIRTIO/ everywhere. > >     The result is very close to one produced by exporting from the >     ODF we were supplied, with the exception of the TOC formatting, >     where section numbers are in blue instead of black, and major >     sections don't have dots leading to page numbers. > >     I'm guessing this isn't very important, someone with more latex >     knowledge can try to figure this out. > >     Generating html doesn't actually work for me. >     It doesn't work for me for CMIS either, so >     it's probably just an issue with my local latex setup. > >     I'm not sure we need html output at all. > >     The PDF output is attached. > >     For the curious, the source can temporarily be seen in my private >     repository here: >     git:// git.kernel.org/pub/scm/virt/kvm/mst/virtio-text.git latex > >     If that's OK with everyone, I can commit >     the result and we can convert from text to this template. > >     -- >     MST > > >     --------------------------------------------------------------------- >     To unsubscribe from this mail list, you must leave the OASIS TC that >     generates this mail.  Follow this link to all your TCs in OASIS at: >     https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > -- > > /chet  > ---------------- > Chet Ensign > Director of Standards Development and TC Administration  > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-996-2298 > Mobile: +1 201-341-1393   > > Check your work using the Support Request Submission Checklist at http:// > www.oasis-open.org/committees/download.php/47248/ > tc-admin-submission-checklist.html  > > TC Administration information and support is available at http:// > www.oasis-open.org/resources/tcadmin > > Follow OASIS on: > LinkedIn:     http://linkd.in/OASISopen > Twitter:         http://twitter.com/OASISopen > Facebook:   http://facebook.com/oasis.open --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

I'd like to but generating HTML needs htlatex which seems to at the moment be broken on my Fedora install. I'm investigating. On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > Great, thanks for that. Paul and I will get feedback to you on what we see in > the PDF in the next day or two. If you could also generate an HTML copy and > send it to us, that would be helpful too.  > > Best,  > > /chet > > > On Mon, Nov 18, 2013 at 9:54 AM, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Mon, Nov 18, 2013 at 09:41:43AM -0500, Chet Ensign wrote: > > Hi Michael, hi Rusty,  > > > > Let me jump in and help out here a bit.  > > > > By using latex as your source, you will be taking responsibility for > generating > > the editable source, HTML and PDF editions that TC Admin normally > prepares for > > the Technical Committees from odf or doc working draft files.  > > > > So you will need to work with us to establish all the proper metadata is > there > > and in the proper format. We worked with the CMIS TC to get this all down > right > > & will gladly work with you to make sure everything is in the proper > shape and > > form.  > > > > I haven't looked at the pdf attached yet - I'll do so today. Paul and I > can > > prep a list of metadata for you.  > > > > What kind of timeframe are you looking for? When do you want the TC to be > able > > to vote to approve the draft?  > > > > Thanks,  > > > > /chet  > > > > I think the plan was Dec 3.  The text is approved by now.  Of course we > still actually need to prepare it in the correct format and give people > time to review. > > > On Sun, Nov 17, 2013 at 8:18 AM, Michael S. Tsirkin <mst@redhat.com> > wrote: > > > >     I imported latex templates from the CMIS specifications > >     and changed s/CMIS/VIRTIO/ everywhere. > > > >     The result is very close to one produced by exporting from the > >     ODF we were supplied, with the exception of the TOC formatting, > >     where section numbers are in blue instead of black, and major > >     sections don't have dots leading to page numbers. > > > >     I'm guessing this isn't very important, someone with more latex > >     knowledge can try to figure this out. > > > >     Generating html doesn't actually work for me. > >     It doesn't work for me for CMIS either, so > >     it's probably just an issue with my local latex setup. > > > >     I'm not sure we need html output at all. > > > >     The PDF output is attached. > > > >     For the curious, the source can temporarily be seen in my private > >     repository here: > >     git://git.kernel.org/pub/scm/virt/kvm/mst/virtio-text.git latex > > > >     If that's OK with everyone, I can commit > >     the result and we can convert from text to this template. > > > >     -- > >     MST > > > > > >     --------------------------------------------------------------------- > >     To unsubscribe from this mail list, you must leave the OASIS TC that > >     generates this mail.  Follow this link to all your TCs in OASIS at: > >     https://www.oasis-open.org/apps/org/workgroup/portal/ > my_workgroups.php > > > > > > > > > > -- > > > > /chet  > > ---------------- > > Chet Ensign > > Director of Standards Development and TC Administration  > > OASIS: Advancing open standards for the information society > > http://www.oasis-open.org > > > > Primary: +1 973-996-2298 > > Mobile: +1 201-341-1393  > > > > Check your work using the Support Request Submission Checklist at http:// > > www.oasis-open.org/committees/download.php/47248/ > > tc-admin-submission-checklist.html  > > > > TC Administration information and support is available at http:// > > www.oasis-open.org/resources/tcadmin > > > > Follow OASIS on: > > LinkedIn:     http://linkd.in/OASISopen > > Twitter:         http://twitter.com/OASISopen > > Facebook:   http://facebook.com/oasis.open > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > -- > > /chet  > ---------------- > Chet Ensign > Director of Standards Development and TC Administration  > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-996-2298 > Mobile: +1 201-341-1393  > > Check your work using the Support Request Submission Checklist at http:// > www.oasis-open.org/committees/download.php/47248/ > tc-admin-submission-checklist.html  > > TC Administration information and support is available at http:// > www.oasis-open.org/resources/tcadmin > > Follow OASIS on: > LinkedIn:     http://linkd.in/OASISopen > Twitter:         http://twitter.com/OASISopen > Facebook:   http://facebook.com/oasis.open

On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > Great, thanks for that. Paul and I will get feedback to you on what we see in > the PDF in the next day or two. If you could also generate an HTML copy and > send it to us, that would be helpful too.  > > Best,  > > /chet OK for now I just commented the following last line in htlatex: t4ht -f/$1 $4 ## -d~/WWW/temp/ -m644 I don't know what it was supposed to do but t4ht seems broken on my system: #!/bin/sh $1 $2 $1 $2 $1 $2 tex4ht $2 t4ht $2 $3 which makes it recursively re-invoke itself apparently forever. Resulting HTML attached. Attachment: virtio-v1.0-csd01.zip Description: Zip archive

On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > Great, thanks for that. Paul and I will get feedback to you on what we see in > the PDF in the next day or two. If you could also generate an HTML copy and > send it to us, that would be helpful too.  > > Best,  > > /chet Didn't get a response yet so I went ahead and committed it. I also started converting the spec text to this format. The initial conversion was done using a perl script. I added that to subversion too in case people are curious or in case we need to re-do the conversion. -- MST

On Mon, Nov 25, 2013 at 02:21:55PM +0200, Michael S. Tsirkin wrote: > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > the PDF in the next day or two. If you could also generate an HTML copy and > > send it to us, that would be helpful too.  > > > > Best,  > > > > /chet > > Didn't get a response yet so I went ahead and committed it. > I also started converting the spec text to this format. > The initial conversion was done using a perl script. > I added that to subversion too in case people are curious > or in case we need to re-do the conversion. Results attached. PDF looks mostly OK. HTML doesn't because listings and verbatim sections are not converted to fixed-width text propertly, but should be enough for you to check the overall structure fits the requirements. Attachment: virtio-v1.0-csd01-html.zip Description: Zip archive Attachment: virtio-v1.0-csd01.pdf Description: Adobe PDF document

On Mon, Nov 25, 2013 at 02:42:24PM +0200, Michael S. Tsirkin wrote: > On Mon, Nov 25, 2013 at 02:21:55PM +0200, Michael S. Tsirkin wrote: > > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > > the PDF in the next day or two. If you could also generate an HTML copy and > > > send it to us, that would be helpful too.  > > > > > > Best,  > > > > > > /chet > > > > Didn't get a response yet so I went ahead and committed it. > > I also started converting the spec text to this format. > > The initial conversion was done using a perl script. > > I added that to subversion too in case people are curious > > or in case we need to re-do the conversion. > > Results attached. PDF looks mostly OK. HTML doesn't because > listings and verbatim sections are not converted to fixed-width text > propertly, but should be enough for you to check the overall > structure fits the requirements. I worked-around this last issue: apparently .css didn't get generated, I get an empty .css after running htlatex. I added a hard-coded css for now. This could be a Fedora specific issue: does this work for others? -- MST

On Mon, 25 Nov 2013 16:20:33 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Nov 25, 2013 at 02:42:24PM +0200, Michael S. Tsirkin wrote: > > On Mon, Nov 25, 2013 at 02:21:55PM +0200, Michael S. Tsirkin wrote: > > > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > > > the PDF in the next day or two. If you could also generate an HTML copy and > > > > send it to us, that would be helpful too.  > > > > > > > > Best,  > > > > > > > > /chet > > > > > > Didn't get a response yet so I went ahead and committed it. > > > I also started converting the spec text to this format. > > > The initial conversion was done using a perl script. > > > I added that to subversion too in case people are curious > > > or in case we need to re-do the conversion. > > > > Results attached. PDF looks mostly OK. HTML doesn't because > > listings and verbatim sections are not converted to fixed-width text > > propertly, but should be enough for you to check the overall > > structure fits the requirements. > > I worked-around this last issue: apparently .css didn't get > generated, I get an empty .css after running htlatex. > I added a hard-coded css for now. > This could be a Fedora specific issue: does this work for others? > If I remove your t4ht dummy script, it works for me. System is Ubuntu 12.04: t4ht.c (2009-01-31-07:34 kpathsea) Package tex4ht 20090611-1.1 (no idea which upstream this corresponds to)

On Mon, Nov 25, 2013 at 04:03:11PM +0100, Cornelia Huck wrote: > On Mon, 25 Nov 2013 16:20:33 +0200 > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Mon, Nov 25, 2013 at 02:42:24PM +0200, Michael S. Tsirkin wrote: > > > On Mon, Nov 25, 2013 at 02:21:55PM +0200, Michael S. Tsirkin wrote: > > > > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > > > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > > > > the PDF in the next day or two. If you could also generate an HTML copy and > > > > > send it to us, that would be helpful too.  > > > > > > > > > > Best,  > > > > > > > > > > /chet > > > > > > > > Didn't get a response yet so I went ahead and committed it. > > > > I also started converting the spec text to this format. > > > > The initial conversion was done using a perl script. > > > > I added that to subversion too in case people are curious > > > > or in case we need to re-do the conversion. > > > > > > Results attached. PDF looks mostly OK. HTML doesn't because > > > listings and verbatim sections are not converted to fixed-width text > > > propertly, but should be enough for you to check the overall > > > structure fits the requirements. > > > > I worked-around this last issue: apparently .css didn't get > > generated, I get an empty .css after running htlatex. > > I added a hard-coded css for now. > > This could be a Fedora specific issue: does this work for others? > > > > If I remove your t4ht dummy script, it works for me. > > System is Ubuntu 12.04: > > t4ht.c (2009-01-31-07:34 kpathsea) > > Package tex4ht 20090611-1.1 (no idea which upstream this corresponds > to) OK I moved the work-around to its own subdirectory, and disabled it by default. Made it work on Fedora by using an old binary.

On Mon, 25 Nov 2013 14:21:55 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > the PDF in the next day or two. If you could also generate an HTML copy and > > send it to us, that would be helpful too.  > > > > Best,  > > > > /chet > > Didn't get a response yet so I went ahead and committed it. > I also started converting the spec text to this format. > The initial conversion was done using a perl script. > I added that to subversion too in case people are curious > or in case we need to re-do the conversion. Builds on my Precise system. Some things I noticed at a first glance: - We'll need to convert the remaining ascii tables to proper tables. - Index starts with '1 Introduction'; you can't get to the start of the document via the index. - There are a lot of field names, defines, etc. inline, which probably need some kind of visual differentiation (verbatim{}?) How is this handled in other standards?

On Mon, 25 Nov 2013 13:58:36 +0100 Cornelia Huck <cornelia.huck@de.ibm.com> wrote: > On Mon, 25 Nov 2013 14:21:55 +0200 > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > > the PDF in the next day or two. If you could also generate an HTML copy and > > > send it to us, that would be helpful too.  > > > > > > Best,  > > > > > > /chet > > > > Didn't get a response yet so I went ahead and committed it. > > I also started converting the spec text to this format. > > The initial conversion was done using a perl script. > > I added that to subversion too in case people are curious > > or in case we need to re-do the conversion. > > Builds on my Precise system. > > Some things I noticed at a first glance: > > - We'll need to convert the remaining ascii tables to proper tables. > - Index starts with '1 Introduction'; you can't get to the start of the > document via the index. > - There are a lot of field names, defines, etc. inline, which probably > need some kind of visual differentiation (verbatim{}?) How is this s/verbatim/texttt/ At least that's what I've used in similar documents. > handled in other standards?

On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: > On Mon, 25 Nov 2013 13:58:36 +0100 > Cornelia Huck <cornelia.huck@de.ibm.com> wrote: > > > On Mon, 25 Nov 2013 14:21:55 +0200 > > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > > > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > > > the PDF in the next day or two. If you could also generate an HTML copy and > > > > send it to us, that would be helpful too.  > > > > > > > > Best,  > > > > > > > > /chet > > > > > > Didn't get a response yet so I went ahead and committed it. > > > I also started converting the spec text to this format. > > > The initial conversion was done using a perl script. > > > I added that to subversion too in case people are curious > > > or in case we need to re-do the conversion. > > > > Builds on my Precise system. > > > > Some things I noticed at a first glance: > > > > - We'll need to convert the remaining ascii tables to proper tables. Yes. There are only 9 of these and already marked explicitly using verbatim so not a big deal to do manually. > > - Index starts with '1 Introduction'; you can't get to the start of the > > document via the index. Same's true for the template that we were sent. > > - There are a lot of field names, defines, etc. inline, which probably > > need some kind of visual differentiation (verbatim{}?) How is this > > s/verbatim/texttt/ > > At least that's what I've used in similar documents. emph is also common It might be nice to make them links to the field definition too. > > handled in other standards? I think it's not a must. virtio spec 0.9.5 made them inline initially. > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: > On Mon, 25 Nov 2013 13:58:36 +0100 > Cornelia Huck <cornelia.huck@de.ibm.com> wrote: > > > On Mon, 25 Nov 2013 14:21:55 +0200 > > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > > > On Mon, Nov 18, 2013 at 09:57:52AM -0500, Chet Ensign wrote: > > > > Great, thanks for that. Paul and I will get feedback to you on what we see in > > > > the PDF in the next day or two. If you could also generate an HTML copy and > > > > send it to us, that would be helpful too.  > > > > > > > > Best,  > > > > > > > > /chet > > > > > > Didn't get a response yet so I went ahead and committed it. > > > I also started converting the spec text to this format. > > > The initial conversion was done using a perl script. > > > I added that to subversion too in case people are curious > > > or in case we need to re-do the conversion. > > > > Builds on my Precise system. > > > > Some things I noticed at a first glance: > > > > - We'll need to convert the remaining ascii tables to proper tables. > > - Index starts with '1 Introduction'; you can't get to the start of the > > document via the index. > > - There are a lot of field names, defines, etc. inline, which probably > > need some kind of visual differentiation (verbatim{}?) How is this > > s/verbatim/texttt/ > > At least that's what I've used in similar documents. > > > handled in other standards? Also if you are inclined to do this conversion all over, please take a look at pre-defined virtioattribute/virtioproperty/ virtiodescription etc in commands-pdf.tex and commands-html.tex These have the advantage of already being supported in html.

On Mon, 25 Nov 2013 15:57:52 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: > > On Mon, 25 Nov 2013 13:58:36 +0100 > > Cornelia Huck <cornelia.huck@de.ibm.com> wrote: > > > > > On Mon, 25 Nov 2013 14:21:55 +0200 > > > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > - There are a lot of field names, defines, etc. inline, which probably > > > need some kind of visual differentiation (verbatim{}?) How is this > > > > s/verbatim/texttt/ > > > > At least that's what I've used in similar documents. > > > > > handled in other standards? > > Also if you are inclined to do this conversion all over, > please take a look at pre-defined virtioattribute/virtioproperty/ > virtiodescription etc in commands-pdf.tex and commands-html.tex > > These have the advantage of already being supported in html. > I hadn't looked at the defined environments yet, but this looks like a good idea. I'll see what I can do.

Hi all, I'm glad to see that the TC has settled on using LaTeX to produce the Virtio specification. The HTML and PDF versions look like they are on the right track, but will need to have a number of adjustments to match the publication formats used for OASIS Work Products (as opposed to the "working draft" formats, which omit several elements which are pretty tricky).   Since (by using LaTeX) you will be handling every aspect of producing the PDF and HTML files, you'll need a complete example of the expected front pages.  That is in the attached ZIP file. Assuming you want to have a formal Public Review when you publish the first Committee Specification Draft, you will actually need to produce TWO parallel sets of files: - Committee Specification Draft 01 (csd01) - Committee Specification Public Review Draft 01 (csprd01) In the attached ZIP file, I've included examples of the expected publishable csd01 front pages (in HTML, PDF, and source DOC formats), the publishable csprd01 front pages (DOC only), and our internal checklist of changes from csd01 to csprd01. You'll need to follow these front page formats exactly as you prepare the documents for publication. Chet and I are very happy to review your planned materials before you submit them.  Our experience has been that it takes a few iterations to get everything completely ready, especially for the first (csd01/csprd01) publication. Best regards, Paul On Mon, Nov 25, 2013 at 9:49 AM, Cornelia Huck < cornelia.huck@de.ibm.com > wrote: On Mon, 25 Nov 2013 15:57:52 +0200 "Michael S. Tsirkin" < mst@redhat.com > wrote: > On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: > > On Mon, 25 Nov 2013 13:58:36 +0100 > > Cornelia Huck < cornelia.huck@de.ibm.com > wrote: > > > > > On Mon, 25 Nov 2013 14:21:55 +0200 > > > "Michael S. Tsirkin" < mst@redhat.com > wrote: > > > - There are a lot of field names, defines, etc. inline, which probably > > >   need some kind of visual differentiation (verbatim{}?) How is this > > > > s/verbatim/texttt/ > > > > At least that's what I've used in similar documents. > > > > >   handled in other standards? > > Also if you are inclined to do this conversion all over, > please take a look at pre-defined virtioattribute/virtioproperty/ > virtiodescription etc in commands-pdf.tex and commands-html.tex > > These have the advantage of already being supported in html. > I hadn't looked at the defined environments yet, but this looks like a good idea. I'll see what I can do. -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst Attachment: virtio-v1.0-csd01-front-pages.zip Description: Zip archive

Hi all, I wanted to mention one other item, after looking through the specification in detail. (Nice work, by the way!!)  This is regarding Section 7 (virtio_ring.h listing).  It's fine to include this, but the TC Process [1] has specific requirements for handling listings like this: " All normative computer language definitions must be provided in separate plain text files [...] " (Actually, if Section 7 is declared to be non-normative, you could avoid this, but I imagine implementers might appreciate it anyway...) You will need to provide the file for this, and also a pointer to it from the front pages. Details: - under "Additional artifacts:" on the front page, change the bullet "XML schemas" to something like Example driver listing: http://docs.oasis-open.org/virtio/virtio/v1.0/csd01/listings/ - Also, within Section 7, note that the file is available - using text like: "This file is available at the link provided in the "Additional artifacts" section on the front page." [using this indirect reference, only the front page needs to be changed as the Work Product moves through various stages - the reference text in Section 7 would remain static] [1]  https://www.oasis-open.org/policies-guidelines/tc-process#specQuality  (see particularly section 7(a)). Best regards, Paul On Mon, Nov 25, 2013 at 10:22 AM, Paul Knight < paul.knight@oasis-open.org > wrote: Hi all, I'm glad to see that the TC has settled on using LaTeX to produce the Virtio specification. The HTML and PDF versions look like they are on the right track, but will need to have a number of adjustments to match the publication formats used for OASIS Work Products (as opposed to the "working draft" formats, which omit several elements which are pretty tricky).   Since (by using LaTeX) you will be handling every aspect of producing the PDF and HTML files, you'll need a complete example of the expected front pages.  That is in the attached ZIP file. Assuming you want to have a formal Public Review when you publish the first Committee Specification Draft, you will actually need to produce TWO parallel sets of files: - Committee Specification Draft 01 (csd01) - Committee Specification Public Review Draft 01 (csprd01) In the attached ZIP file, I've included examples of the expected publishable csd01 front pages (in HTML, PDF, and source DOC formats), the publishable csprd01 front pages (DOC only), and our internal checklist of changes from csd01 to csprd01. You'll need to follow these front page formats exactly as you prepare the documents for publication. Chet and I are very happy to review your planned materials before you submit them.  Our experience has been that it takes a few iterations to get everything completely ready, especially for the first (csd01/csprd01) publication. Best regards, Paul On Mon, Nov 25, 2013 at 9:49 AM, Cornelia Huck < cornelia.huck@de.ibm.com > wrote: On Mon, 25 Nov 2013 15:57:52 +0200 "Michael S. Tsirkin" < mst@redhat.com > wrote: > On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: > > On Mon, 25 Nov 2013 13:58:36 +0100 > > Cornelia Huck < cornelia.huck@de.ibm.com > wrote: > > > > > On Mon, 25 Nov 2013 14:21:55 +0200 > > > "Michael S. Tsirkin" < mst@redhat.com > wrote: > > > - There are a lot of field names, defines, etc. inline, which probably > > >   need some kind of visual differentiation (verbatim{}?) How is this > > > > s/verbatim/texttt/ > > > > At least that's what I've used in similar documents. > > > > >   handled in other standards? > > Also if you are inclined to do this conversion all over, > please take a look at pre-defined virtioattribute/virtioproperty/ > virtiodescription etc in commands-pdf.tex and commands-html.tex > > These have the advantage of already being supported in html. > I hadn't looked at the defined environments yet, but this looks like a good idea. I'll see what I can do. -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

On Mon, Nov 25, 2013 at 11:05:33AM -0500, Paul Knight wrote: > Hi all, > > I wanted to mention one other item, after looking through the specification in > detail. (Nice work, by the way!!)  > > This is regarding Section 7 (virtio_ring.h listing).  It's fine to include > this, but the TC Process [1] has specific requirements for handling listings > like this: > > "All normative computer language definitions must be provided in separate plain > text files [...]" > > (Actually, if Section 7 is declared to be non-normative, you could avoid this, > but I imagine implementers might appreciate it anyway...) Well it is non-normative actually. Do we need to include specific text to mark it as such? > You will need to provide the file for this, and also a pointer to it from the > front pages. > Details: > - under "Additional artifacts:" on the front page, change the bullet "XML > schemas" to something like > > Example driver listing: > http://docs.oasis-open.org/virtio/virtio/v1.0/csd01/listings/ > > - Also, within Section 7, note that the file is available - using text like: > "This file is available at the link provided in the "Additional artifacts" > section on the front page." > > [using this indirect reference, only the front page needs to be changed as the > Work Product moves through various stages - the reference text in Section 7 > would remain static] > > [1]  https://www.oasis-open.org/policies-guidelines/tc-process#specQuality  ;(see > particularly section 7(a)). > > Best regards, > Paul > Will do. Including the link directly is not hard either - we re-compile it all at each stage, anyway. > On Mon, Nov 25, 2013 at 10:22 AM, Paul Knight <paul.knight@oasis-open.org> > wrote: > > Hi all, > > I'm glad to see that the TC has settled on using LaTeX to produce the > Virtio specification. > > The HTML and PDF versions look like they are on the right track, but will > need to have a number of adjustments to match the publication formats used > for OASIS Work Products (as opposed to the "working draft" formats, which > omit several elements which are pretty tricky).   > > Since (by using LaTeX) you will be handling every aspect of producing the > PDF and HTML files, you'll need a complete example of the expected front > pages.  That is in the attached ZIP file. > > Assuming you want to have a formal Public Review when you publish the first > Committee Specification Draft, you will actually need to produce TWO > parallel sets of files: > - Committee Specification Draft 01 (csd01) > - Committee Specification Public Review Draft 01 (csprd01) > > In the attached ZIP file, I've included examples of the expected > publishable csd01 front pages (in HTML, PDF, and source DOC formats), the > publishable csprd01 front pages (DOC only), and our internal checklist of > changes from csd01 to csprd01. > > You'll need to follow these front page formats exactly as you prepare the > documents for publication. > Chet and I are very happy to review your planned materials before you > submit them.  Our experience has been that it takes a few iterations to get > everything completely ready, especially for the first (csd01/csprd01) > publication. > > Best regards, > Paul > > > On Mon, Nov 25, 2013 at 9:49 AM, Cornelia Huck <cornelia.huck@de.ibm.com> > wrote: > > On Mon, 25 Nov 2013 15:57:52 +0200 > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: > > > On Mon, 25 Nov 2013 13:58:36 +0100 > > > Cornelia Huck <cornelia.huck@de.ibm.com> wrote: > > > > > > > On Mon, 25 Nov 2013 14:21:55 +0200 > > > > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > > > - There are a lot of field names, defines, etc. inline, which > probably > > > >   need some kind of visual differentiation (verbatim{}?) How is > this > > > > > > s/verbatim/texttt/ > > > > > > At least that's what I've used in similar documents. > > > > > > >   handled in other standards? > > > > Also if you are inclined to do this conversion all over, > > please take a look at pre-defined virtioattribute/virtioproperty/ > > virtiodescription etc in commands-pdf.tex and commands-html.tex > > > > These have the advantage of already being supported in html. > > > > I hadn't looked at the defined environments yet, but this looks like a > good idea. I'll see what I can do. > > > > > > -- > Paul Knight  - Tel: +1 781-861-1013 > OASIS - Advancing open standards for the information society > Document Process Analyst > > > > > > -- > Paul Knight  - Tel: +1 781-861-1013 > OASIS - Advancing open standards for the information society > Document Process Analyst >

Hi all, An answer for Michael's question is below, in-line. Also one more point - there needs to be some meaningful content in the "Conformance" section before the specification can move to the Public Review stage or beyond. (Required by the TC Process.) On Mon, Nov 25, 2013 at 11:15 AM, Michael S. Tsirkin < mst@redhat.com > wrote: On Mon, Nov 25, 2013 at 11:05:33AM -0500, Paul Knight wrote: > Hi all, > > I wanted to mention one other item, after looking through the specification in > detail. (Nice work, by the way!!)  > > This is regarding Section 7 (virtio_ring.h listing).  It's fine to include > this, but the TC Process [1] has specific requirements for handling listings > like this: > > "All normative computer language definitions must be provided in separate plain > text files [...]" > > (Actually, if Section 7 is declared to be non-normative, you could avoid this, > but I imagine implementers might appreciate it anyway...) Well it is non-normative actually. Do we need to include specific text to mark it as such? It is not required to mark it as non-normative (in order for it to be published, anyway), but by default, everything is considered to be normative unless otherwise labeled. Some TCs have found it helpful to use a distinctive font or background shading to identify "examples", and use an example statement such as "Non-normative examples use this paragraph style". For this approach, see  http://docs.oasis-open.org/odata/odata/v4.0/csprd03/part1-protocol/odata-v4.0-csprd03-part1-protocol.html#_Toc369182979 Best regards, Paul > You will need to provide the file for this, and also a pointer to it from the > front pages. > Details: > - under "Additional artifacts:" on the front page, change the bullet "XML > schemas" to something like > > Example driver listing: > http://docs.oasis-open.org/virtio/virtio/v1.0/csd01/listings/ > > - Also, within Section 7, note that the file is available - using text like: > "This file is available at the link provided in the "Additional artifacts" > section on the front page." > > [using this indirect reference, only the front page needs to be changed as the > Work Product moves through various stages - the reference text in Section 7 > would remain static] > > [1]  https://www.oasis-open.org/policies-guidelines/tc-process#specQuality  (see > particularly section 7(a)). > > Best regards, > Paul > Will do. Including the link directly is not hard either - we re-compile it all at each stage, anyway. A nice feature of automated publishing!  > On Mon, Nov 25, 2013 at 10:22 AM, Paul Knight < paul.knight@oasis-open.org > > wrote: > >     Hi all, > >     I'm glad to see that the TC has settled on using LaTeX to produce the >     Virtio specification. > >     The HTML and PDF versions look like they are on the right track, but will >     need to have a number of adjustments to match the publication formats used >     for OASIS Work Products (as opposed to the "working draft" formats, which >     omit several elements which are pretty tricky).   > >     Since (by using LaTeX) you will be handling every aspect of producing the >     PDF and HTML files, you'll need a complete example of the expected front >     pages.  That is in the attached ZIP file. > >     Assuming you want to have a formal Public Review when you publish the first >     Committee Specification Draft, you will actually need to produce TWO >     parallel sets of files: >     - Committee Specification Draft 01 (csd01) >     - Committee Specification Public Review Draft 01 (csprd01) > >     In the attached ZIP file, I've included examples of the expected >     publishable csd01 front pages (in HTML, PDF, and source DOC formats), the >     publishable csprd01 front pages (DOC only), and our internal checklist of >     changes from csd01 to csprd01. > >     You'll need to follow these front page formats exactly as you prepare the >     documents for publication. >     Chet and I are very happy to review your planned materials before you >     submit them.  Our experience has been that it takes a few iterations to get >     everything completely ready, especially for the first (csd01/csprd01) >     publication. > >     Best regards, >     Paul > > >     On Mon, Nov 25, 2013 at 9:49 AM, Cornelia Huck < cornelia.huck@de.ibm.com > >     wrote: > >         On Mon, 25 Nov 2013 15:57:52 +0200 >         "Michael S. Tsirkin" < mst@redhat.com > wrote: > >         > On Mon, Nov 25, 2013 at 02:09:14PM +0100, Cornelia Huck wrote: >         > > On Mon, 25 Nov 2013 13:58:36 +0100 >         > > Cornelia Huck < cornelia.huck@de.ibm.com > wrote: >         > > >         > > > On Mon, 25 Nov 2013 14:21:55 +0200 >         > > > "Michael S. Tsirkin" < mst@redhat.com > wrote: > >         > > > - There are a lot of field names, defines, etc. inline, which >         probably >         > > >   need some kind of visual differentiation (verbatim{}?) How is >         this >         > > >         > > s/verbatim/texttt/ >         > > >         > > At least that's what I've used in similar documents. >         > > >         > > >   handled in other standards? >         > >         > Also if you are inclined to do this conversion all over, >         > please take a look at pre-defined virtioattribute/virtioproperty/ >         > virtiodescription etc in commands-pdf.tex and commands-html.tex >         > >         > These have the advantage of already being supported in html. >         > > >         I hadn't looked at the defined environments yet, but this looks like a >         good idea. I'll see what I can do. > > > > > >     -- >     Paul Knight  - Tel: +1 781-861-1013 >     OASIS - Advancing open standards for the information society >     Document Process Analyst > > > > > > -- > Paul Knight  - Tel: +1 781-861-1013 > OASIS - Advancing open standards for the information society > Document Process Analyst > -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Some questions: I think we prefer the PDF version of the spec to be authoritative one and not the HTML one. Can we change the citation link to point to that? I think we want to also mention the virtio-comment mailing list and not just the web form as a way to submit comments. Is that OK? Do we need to leave stubs for things we don't have? E.g. This specification is related to: Related speifications (list) can we just remove this until we have some related specifications?

Hi Michael and all, Please see below.. On Mon, Nov 25, 2013 at 12:13 PM, Michael S. Tsirkin < mst@redhat.com > wrote: Some questions: I think we prefer the PDF version of the spec to be authoritative one and not the HTML one. Can we change the citation link to point to that? No, please don't... although the HTML may not be authoritative, we want the citation link to point to HTML for easiest retrieval.  Please look at the "front pages" which I provided in the ZIP file, and you'll see that the PDF format is already listed at the top under the "Specification URIs" as "(Authoritative)".  As soon as someone retrieves the HTML, they will see this, so they can get the PDF if desired.  However, our approach is to consider that many busy people just want to glance at the specification, and might be deterred by having to retrieve a PDF of unknown length. The "citation format" is intended to be included as a reference in some other document, so we'd like people to be inclined to look at the OASIS docs...  Of course, if you are sending links to people, please feel free to send the PDF link... I think we want to also mention the virtio-comment mailing list and not just the web form as a way to submit comments. Is that OK? I believe the link goes to the page ( http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio ) where they can first subscribe, then they can go to the comment page.  People can't comment until they subscribe.  OASIS IPR rules require this...  (imagine a "patent troll" submits their patented idea as a nice addition to the spec, then claims all kinds of damages, etc...  the subscription process helps prevent this...) (very loooong story...) This is boilerplate info which we want to keep standard... Do we need to leave stubs for things we don't have? E.g. This specification is related to:     Related speifications (list) can we just remove this until we have some related specifications? Yes, please remove any unwanted/unused sections completely (other than the "Previous version").  Hope that all makes sense...   Best regards, Paul -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

On Mon, Nov 25, 2013 at 12:43:39PM -0500, Paul Knight wrote: > Hi Michael and all, > Please see below.. > > On Mon, Nov 25, 2013 at 12:13 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > > Some questions: > > I think we prefer the PDF version of the spec to > be authoritative one and not the HTML one. > Can we change the citation link to point to that? > > No, please don't... although the HTML may not be authoritative, we want the > citation link to point to HTML for easiest retrieval. Okay. BTW in what way do we supply the files? Can chair just upload them? >  Please look at the > "front pages" which I provided in the ZIP file, and you'll see that the PDF > format is already listed at the top under the "Specification URIs" as " > (Authoritative)".  As soon as someone retrieves the HTML, they will see this, > so they can get the PDF if desired.  However, our approach is to consider that > many busy people just want to glance at the specification, and might be > deterred by having to retrieve a PDF of unknown length. > > The "citation format" is intended to be included as a reference in some other > document, so we'd like people to be inclined to look at the OASIS docs...  Of > course, if you are sending links to people, please feel free to send the PDF > link... > > > I think we want to also mention the virtio-comment mailing > list and not just the web form as a way to submit comments. > Is that OK? > > I believe the link goes to the page > ( http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio ) > where they can first subscribe, then they can go to the comment page.  People > can't comment until they subscribe.  OASIS IPR rules require this...  (imagine > a "patent troll" submits their patented idea as a nice addition to the spec, > then claims all kinds of damages, etc...  the subscription process helps > prevent this...) (very loooong story...) > This is boilerplate info which we want to keep standard... > > > Do we need to leave stubs for things we don't have? > E.g. > This specification is related to: >     Related speifications (list) > > can we just remove this until we have some related specifications? > > Yes, please remove any unwanted/unused sections completely (other than the > "Previous version").  > > Hope that all makes sense...   > > Best regards, > Paul > -- > Paul Knight  - Tel: +1 781-861-1013 > OASIS - Advancing open standards for the information society > Document Process Analyst >

Hi Michael, Waaay back at the beginning... the "transmittal message"... https://lists.oasis-open.org/archives/virtio/201311/msg00038.html .. had the basic info, below: [....]   When the TC votes [5] to approve a Working Draft as a Committee Draft (CSD or CND), the Chair or other designated person must submit a "Committee Specification Draft Creation and Upload Request" accessible on the TC Administration Requests Page [6].   [5] Approval of a WD as a CD (CSD or CND)      https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft      https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft [6] TC Administration Requests Page, see Committee Specification Draft Creation / Upload Request      https://www.oasis-open.org/resources/tc-admin-requests Very briefly, ZIP up everything (one ZIP for csd01, one for csprd01) and load it to Kavi, and then have the TC vote to approve it.  After that, fill out the forms in [6] and we'll get started on publishing it.  By the TC Process, we can (if needed) adjust things on the front pages (through the TOC) after the TC approves it, but other changes are not allowed without re-approval. For the first publication using LaTeX, it's best to give us (Chet and me) a look before having the TC approve it. Best regards, Paul On Mon, Nov 25, 2013 at 2:05 PM, Michael S. Tsirkin < mst@redhat.com > wrote: On Mon, Nov 25, 2013 at 12:43:39PM -0500, Paul Knight wrote: > Hi Michael and all, > Please see below.. > > On Mon, Nov 25, 2013 at 12:13 PM, Michael S. Tsirkin < mst@redhat.com > wrote: > >     Some questions: > >     I think we prefer the PDF version of the spec to >     be authoritative one and not the HTML one. >     Can we change the citation link to point to that? > > No, please don't... although the HTML may not be authoritative, we want the > citation link to point to HTML for easiest retrieval. Okay. BTW in what way do we supply the files? Can chair just upload them? >  Please look at the > "front pages" which I provided in the ZIP file, and you'll see that the PDF > format is already listed at the top under the "Specification URIs" as " > (Authoritative)".  As soon as someone retrieves the HTML, they will see this, > so they can get the PDF if desired.  However, our approach is to consider that > many busy people just want to glance at the specification, and might be > deterred by having to retrieve a PDF of unknown length. > > The "citation format" is intended to be included as a reference in some other > document, so we'd like people to be inclined to look at the OASIS docs...  Of > course, if you are sending links to people, please feel free to send the PDF > link... > > >     I think we want to also mention the virtio-comment mailing >     list and not just the web form as a way to submit comments. >     Is that OK? > > I believe the link goes to the page > ( http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio ) > where they can first subscribe, then they can go to the comment page.  People > can't comment until they subscribe.  OASIS IPR rules require this...  (imagine > a "patent troll" submits their patented idea as a nice addition to the spec, > then claims all kinds of damages, etc...  the subscription process helps > prevent this...) (very loooong story...) > This is boilerplate info which we want to keep standard... > > >     Do we need to leave stubs for things we don't have? >     E.g. >     This specification is related to: >         Related speifications (list) > >     can we just remove this until we have some related specifications? > > Yes, please remove any unwanted/unused sections completely (other than the > "Previous version").  > > Hope that all makes sense...   > > Best regards, > Paul > -- > Paul Knight  - Tel: +1 781-861-1013 > OASIS - Advancing open standards for the information society > Document Process Analyst > -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Hi Paul, Chet, I did this submission last week, the day after the meeting. Is there anything else I need to do? Cheers, Rusty. Paul Knight <paul.knight@oasis-open.org> writes: > Hi Michael, > > Waaay back at the beginning... the "transmittal message"... > https://lists.oasis-open.org/archives/virtio/201311/msg00038.html > > .. had the basic info, below: > > [....] When the TC votes [5] to approve a Working Draft as a Committee > Draft (CSD or CND), the Chair or other designated person must submit a > "Committee Specification Draft Creation and Upload Request" accessible on > the TC Administration Requests Page [6]. > > [5] Approval of a WD as a CD (CSD or CND) > > https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft > https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft > [6] TC Administration Requests Page, see Committee Specification Draft > Creation / Upload Request > https://www.oasis-open.org/resources/tc-admin-requests > > Very briefly, ZIP up everything (one ZIP for csd01, one for csprd01) and > load it to Kavi, and then have the TC vote to approve it. After that, fill > out the forms in [6] and we'll get started on publishing it. By the TC > Process, we can (if needed) adjust things on the front pages (through the > TOC) after the TC approves it, but other changes are not allowed without > re-approval. > > For the first publication using LaTeX, it's best to give us (Chet and me) a > look before having the TC approve it. > > Best regards, > Paul > > > > On Mon, Nov 25, 2013 at 2:05 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > >> On Mon, Nov 25, 2013 at 12:43:39PM -0500, Paul Knight wrote: >> > Hi Michael and all, >> > Please see below.. >> > >> > On Mon, Nov 25, 2013 at 12:13 PM, Michael S. Tsirkin <mst@redhat.com> >> wrote: >> > >> > Some questions: >> > >> > I think we prefer the PDF version of the spec to >> > be authoritative one and not the HTML one. >> > Can we change the citation link to point to that? >> > >> > No, please don't... although the HTML may not be authoritative, we want >> the >> > citation link to point to HTML for easiest retrieval. >> >> Okay. >> BTW in what way do we supply the files? Can chair just upload them? >> >> >> > Please look at the >> > "front pages" which I provided in the ZIP file, and you'll see that the >> PDF >> > format is already listed at the top under the "Specification URIs" as " >> > (Authoritative)". As soon as someone retrieves the HTML, they will see >> this, >> > so they can get the PDF if desired. However, our approach is to >> consider that >> > many busy people just want to glance at the specification, and might be >> > deterred by having to retrieve a PDF of unknown length. >> > >> > The "citation format" is intended to be included as a reference in some >> other >> > document, so we'd like people to be inclined to look at the OASIS >> docs... Of >> > course, if you are sending links to people, please feel free to send the >> PDF >> > link... >> > >> > >> > I think we want to also mention the virtio-comment mailing >> > list and not just the web form as a way to submit comments. >> > Is that OK? >> > >> > I believe the link goes to the page >> > ( >> http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio ) >> > where they can first subscribe, then they can go to the comment page. >> People >> > can't comment until they subscribe. OASIS IPR rules require this... >> (imagine >> > a "patent troll" submits their patented idea as a nice addition to the >> spec, >> > then claims all kinds of damages, etc... the subscription process helps >> > prevent this...) (very loooong story...) >> > This is boilerplate info which we want to keep standard... >> > >> > >> > Do we need to leave stubs for things we don't have? >> > E.g. >> > This specification is related to: >> > Related speifications (list) >> > >> > can we just remove this until we have some related specifications? >> > >> > Yes, please remove any unwanted/unused sections completely (other than >> the >> > "Previous version"). >> > >> > Hope that all makes sense... >> > >> > Best regards, >> > Paul >> > -- >> > Paul Knight - Tel: +1 781-861-1013 >> > OASIS - Advancing open standards for the information society >> > Document Process Analyst >> > >> > > > > -- > Paul Knight <paul.knight@oasis-open.org> - Tel: +1 781-861-1013 > OASIS < http://www.oasis-open.org/ > - Advancing open standards for the > information society > Document Process Analyst< http://www.oasis-open.org/people/staff/paul-knight >

Hi Rusty,  Nope, not at all. It is in the queue - tickets  https://tools.oasis-open.org/issues/browse/TCADMIN-1541 and  https://tools.oasis-open.org/issues/browse/TCADMIN-1542 are tracking the work.  You're just in line behind an unusually long list of requests that we are crunching through as fast as we can. I expect to get started working on Virtio tomorrow or Thursday. If you all would like to have the first public review run a bit longer given the holiday impacts, just let me know. The 30 day is the minimum - we can always run it longer if you want.  Best,  /chet  On Mon, Dec 9, 2013 at 11:54 PM, Rusty Russell < rusty@au1.ibm.com > wrote: Hi Paul, Chet,         I did this submission last week, the day after the meeting.  Is there anything else I need to do? Cheers, Rusty. Paul Knight < paul.knight@oasis-open.org > writes: > Hi Michael, > > Waaay back at the beginning... the "transmittal message"... > https://lists.oasis-open.org/archives/virtio/201311/msg00038.html > > .. had the basic info, below: > > [....]  When the TC votes [5] to approve a Working Draft as a Committee > Draft (CSD or CND), the Chair or other designated person must submit a > "Committee Specification Draft Creation and Upload Request" accessible on > the TC Administration Requests Page [6]. > > [5] Approval of a WD as a CD (CSD or CND) > > https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft >     https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft > [6] TC Administration Requests Page, see Committee Specification Draft > Creation / Upload Request >     https://www.oasis-open.org/resources/tc-admin-requests > > Very briefly, ZIP up everything (one ZIP for csd01, one for csprd01) and > load it to Kavi, and then have the TC vote to approve it.  After that, fill > out the forms in [6] and we'll get started on publishing it.  By the TC > Process, we can (if needed) adjust things on the front pages (through the > TOC) after the TC approves it, but other changes are not allowed without > re-approval. > > For the first publication using LaTeX, it's best to give us (Chet and me) a > look before having the TC approve it. > > Best regards, > Paul > > > > On Mon, Nov 25, 2013 at 2:05 PM, Michael S. Tsirkin < mst@redhat.com > wrote: > >> On Mon, Nov 25, 2013 at 12:43:39PM -0500, Paul Knight wrote: >> > Hi Michael and all, >> > Please see below.. >> > >> > On Mon, Nov 25, 2013 at 12:13 PM, Michael S. Tsirkin < mst@redhat.com > >> wrote: >> > >> >     Some questions: >> > >> >     I think we prefer the PDF version of the spec to >> >     be authoritative one and not the HTML one. >> >     Can we change the citation link to point to that? >> > >> > No, please don't... although the HTML may not be authoritative, we want >> the >> > citation link to point to HTML for easiest retrieval. >> >> Okay. >> BTW in what way do we supply the files? Can chair just upload them? >> >> >> >  Please look at the >> > "front pages" which I provided in the ZIP file, and you'll see that the >> PDF >> > format is already listed at the top under the "Specification URIs" as " >> > (Authoritative)".  As soon as someone retrieves the HTML, they will see >> this, >> > so they can get the PDF if desired.  However, our approach is to >> consider that >> > many busy people just want to glance at the specification, and might be >> > deterred by having to retrieve a PDF of unknown length. >> > >> > The "citation format" is intended to be included as a reference in some >> other >> > document, so we'd like people to be inclined to look at the OASIS >> docs...  Of >> > course, if you are sending links to people, please feel free to send the >> PDF >> > link... >> > >> > >> >     I think we want to also mention the virtio-comment mailing >> >     list and not just the web form as a way to submit comments. >> >     Is that OK? >> > >> > I believe the link goes to the page >> > ( >> http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio ) >> > where they can first subscribe, then they can go to the comment page. >>  People >> > can't comment until they subscribe.  OASIS IPR rules require this... >>  (imagine >> > a "patent troll" submits their patented idea as a nice addition to the >> spec, >> > then claims all kinds of damages, etc...  the subscription process helps >> > prevent this...) (very loooong story...) >> > This is boilerplate info which we want to keep standard... >> > >> > >> >     Do we need to leave stubs for things we don't have? >> >     E.g. >> >     This specification is related to: >> >         Related speifications (list) >> > >> >     can we just remove this until we have some related specifications? >> > >> > Yes, please remove any unwanted/unused sections completely (other than >> the >> > "Previous version"). >> > >> > Hope that all makes sense... >> > >> > Best regards, >> > Paul >> > -- >> > Paul Knight  - Tel: +1 781-861-1013 >> > OASIS - Advancing open standards for the information society >> > Document Process Analyst >> > >> > > > > -- > Paul Knight < paul.knight@oasis-open.org >  - Tel: +1 781-861-1013 > OASIS < http://www.oasis-open.org/ > - Advancing open standards for the > information society > Document Process Analyst< http://www.oasis-open.org/people/staff/paul-knight > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

On Tue, Dec 10, 2013 at 10:20:04AM -0500, Chet Ensign wrote: > Hi Rusty, > > Nope, not at all. It is in the queue - tickets > https://tools.oasis-open.org/issues/browse/TCADMIN-1541 and > https://tools.oasis-open.org/issues/browse/TCADMIN-1542 are tracking the > work. Could you add xen-devel@lists.xenproject.org address to the notification list in ticket 1542? This is Xen developer list. You could find more here: http://lists.xenproject.org/ . > You're just in line behind an unusually long list of requests that we are > crunching through as fast as we can. I expect to get started working on > Virtio tomorrow or Thursday. If you all would like to have the first public > review run a bit longer given the holiday impacts, just let me know. The 30 > day is the minimum - we can always run it longer if you want. I am going to take two weeks holiday at the end of the year and I suppose that there are more people with such plans around. So I think that it will be nice to have, let's say, 40 day public review in such case. However, I do not insist on this if we do not have any time constraints between releasing WD01 and WD02. Daniel

Daniel, I'll add that to the ticket. Thanks.  On Wed, Dec 11, 2013 at 3:46 AM, Daniel Kiper < daniel.kiper@oracle.com > wrote: On Tue, Dec 10, 2013 at 10:20:04AM -0500, Chet Ensign wrote: > Hi Rusty, > > Nope, not at all. It is in the queue - tickets > https://tools.oasis-open.org/issues/browse/TCADMIN-1541 and > https://tools.oasis-open.org/issues/browse/TCADMIN-1542 are tracking the > work. Could you add xen-devel@lists.xenproject.org address to the notification list in ticket 1542? This is Xen developer list. You could find more here: http://lists.xenproject.org/ . > You're just in line behind an unusually long list of requests that we are > crunching through as fast as we can. I expect to get started working on > Virtio tomorrow or Thursday. If you all would like to have the first public > review run a bit longer given the holiday impacts, just let me know. The 30 > day is the minimum - we can always run it longer if you want. I am going to take two weeks holiday at the end of the year and I suppose that there are more people with such plans around. So I think that it will be nice to have, let's say, 40 day public review in such case. However, I do not insist on this if we do not have any time constraints between releasing WD01 and WD02. Daniel -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Daniel Kiper <daniel.kiper@oracle.com> writes: > On Tue, Dec 10, 2013 at 10:20:04AM -0500, Chet Ensign wrote: >> Hi Rusty, >> >> Nope, not at all. It is in the queue - tickets >> https://tools.oasis-open.org/issues/browse/TCADMIN-1541 and >> https://tools.oasis-open.org/issues/browse/TCADMIN-1542 are tracking the >> work. > > Could you add xen-devel@lists.xenproject.org address to the notification list > in ticket 1542? This is Xen developer list. You could find more here: > http://lists.xenproject.org/ . > >> You're just in line behind an unusually long list of requests that we are >> crunching through as fast as we can. I expect to get started working on >> Virtio tomorrow or Thursday. If you all would like to have the first public >> review run a bit longer given the holiday impacts, just let me know. The 30 >> day is the minimum - we can always run it longer if you want. > > I am going to take two weeks holiday at the end of the year and I suppose > that there are more people with such plans around. So I think that it > will be nice to have, let's say, 40 day public review in such case. However, > I do not insist on this if we do not have any time constraints between > releasing WD01 and WD02. OK, January 31st? We can process feedback as it comes in, so unless there's massive last-minute feedback, I'd expect we'd still release WD02 early/mid February. Any objections? Cheers, Rusty.

Chet Ensign <chet.ensign@oasis-open.org> writes: > Hi Rusty, > > Nope, not at all. It is in the queue - tickets > https://tools.oasis-open.org/issues/browse/TCADMIN-1541 and > https://tools.oasis-open.org/issues/browse/TCADMIN-1542 are tracking the > work. > > You're just in line behind an unusually long list of requests that we are > crunching through as fast as we can. I expect to get started working on > Virtio tomorrow or Thursday. If you all would like to have the first public > review run a bit longer given the holiday impacts, just let me know. The 30 > day is the minimum - we can always run it longer if you want. > > Best, > > /chet Yes, let's extend it to the 10th January. Our plan was to have a meeting once it's closed, so we can do that on the 14th. Thanks, Rusty.

On Mon, Nov 25, 2013 at 10:22:19AM -0500, Paul Knight wrote: > Hi all, > > I'm glad to see that the TC has settled on using LaTeX to produce the Virtio > specification. > > The HTML and PDF versions look like they are on the right track, but will need > to have a number of adjustments to match the publication formats used for OASIS > Work Products (as opposed to the "working draft" formats, which omit several > elements which are pretty tricky).   > > Since (by using LaTeX) you will be handling every aspect of producing the PDF > and HTML files, you'll need a complete example of the expected front pages. >  That is in the attached ZIP file. > > Assuming you want to have a formal Public Review when you publish the first > Committee Specification Draft, you will actually need to produce TWO parallel > sets of files: > - Committee Specification Draft 01 (csd01) > - Committee Specification Public Review Draft 01 (csprd01) > > In the attached ZIP file, I've included examples of the expected publishable > csd01 front pages (in HTML, PDF, and source DOC formats), the publishable > csprd01 front pages (DOC only), and our internal checklist of changes from > csd01 to csprd01. > > You'll need to follow these front page formats exactly as you prepare the > documents for publication. > Chet and I are very happy to review your planned materials before you submit > them.  Our experience has been that it takes a few iterations to get everything > completely ready, especially for the first (csd01/csprd01) publication. > > Best regards, > Paul OK here's a draft csd for starters, will do csprd01 draft when we are happy with the csd. We still need to fill in the following gaps (for both): - fill in conformance section. Need help from others on this one - fix MUST/SHOULD etc to must/should for consistency - fill in acknowledgements for non-editors who contributed - update procedure on allocating device ids Need feedback from others on this. Paul - anything else that's a must that I missed for CSD? Thanks! -- MST Attachment: virtio-v1.0-csd01.pdf Description: Adobe PDF document

I'll look over the doc in a bit... Regarding acknowledgments, most TCs list all members, rather than trying to figure out who "contributed"...  any member can ask to be listed or excluded, as well. On Mon, Nov 25, 2013 at 2:11 PM, Michael S. Tsirkin < mst@redhat.com > wrote: On Mon, Nov 25, 2013 at 10:22:19AM -0500, Paul Knight wrote: > Hi all, > > I'm glad to see that the TC has settled on using LaTeX to produce the Virtio > specification. > > The HTML and PDF versions look like they are on the right track, but will need > to have a number of adjustments to match the publication formats used for OASIS > Work Products (as opposed to the "working draft" formats, which omit several > elements which are pretty tricky).   > > Since (by using LaTeX) you will be handling every aspect of producing the PDF > and HTML files, you'll need a complete example of the expected front pages. >  That is in the attached ZIP file. > > Assuming you want to have a formal Public Review when you publish the first > Committee Specification Draft, you will actually need to produce TWO parallel > sets of files: > - Committee Specification Draft 01 (csd01) > - Committee Specification Public Review Draft 01 (csprd01) > > In the attached ZIP file, I've included examples of the expected publishable > csd01 front pages (in HTML, PDF, and source DOC formats), the publishable > csprd01 front pages (DOC only), and our internal checklist of changes from > csd01 to csprd01. > > You'll need to follow these front page formats exactly as you prepare the > documents for publication. > Chet and I are very happy to review your planned materials before you submit > them.  Our experience has been that it takes a few iterations to get everything > completely ready, especially for the first (csd01/csprd01) publication. > > Best regards, > Paul OK here's a draft csd for starters, will do csprd01 draft when we are happy with the csd. We still need to fill in the following gaps (for both):  - fill in conformance section. Need help from others on this one  - fix MUST/SHOULD etc to must/should for consistency  - fill in acknowledgements for non-editors who contributed  - update procedure on allocating device ids Need feedback from others on this. Paul - anything else that's a must that I missed for CSD? Thanks! -- MST -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst

Sorry all - catching up on this thread now...  On Mon, Nov 25, 2013 at 2:27 PM, Paul Knight < paul.knight@oasis-open.org > wrote: I'll look over the doc in a bit... Regarding acknowledgments, most TCs list all members, rather than trying to figure out who "contributed"...  any member can ask to be listed or excluded, as well. On Mon, Nov 25, 2013 at 2:11 PM, Michael S. Tsirkin < mst@redhat.com > wrote: On Mon, Nov 25, 2013 at 10:22:19AM -0500, Paul Knight wrote: > Hi all, > > I'm glad to see that the TC has settled on using LaTeX to produce the Virtio > specification. > > The HTML and PDF versions look like they are on the right track, but will need > to have a number of adjustments to match the publication formats used for OASIS > Work Products (as opposed to the "working draft" formats, which omit several > elements which are pretty tricky).   > > Since (by using LaTeX) you will be handling every aspect of producing the PDF > and HTML files, you'll need a complete example of the expected front pages. >  That is in the attached ZIP file. > > Assuming you want to have a formal Public Review when you publish the first > Committee Specification Draft, you will actually need to produce TWO parallel > sets of files: > - Committee Specification Draft 01 (csd01) > - Committee Specification Public Review Draft 01 (csprd01) > > In the attached ZIP file, I've included examples of the expected publishable > csd01 front pages (in HTML, PDF, and source DOC formats), the publishable > csprd01 front pages (DOC only), and our internal checklist of changes from > csd01 to csprd01. > > You'll need to follow these front page formats exactly as you prepare the > documents for publication. > Chet and I are very happy to review your planned materials before you submit > them.  Our experience has been that it takes a few iterations to get everything > completely ready, especially for the first (csd01/csprd01) publication. > > Best regards, > Paul OK here's a draft csd for starters, will do csprd01 draft when we are happy with the csd. We still need to fill in the following gaps (for both):  - fill in conformance section. Need help from others on this one  - fix MUST/SHOULD etc to must/should for consistency  - fill in acknowledgements for non-editors who contributed  - update procedure on allocating device ids Need feedback from others on this. Paul - anything else that's a must that I missed for CSD? Thanks! -- MST -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

Thanks Paul for covering this in such detail. Looks like he has you all up to date.  /chet On Mon, Nov 25, 2013 at 4:29 PM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Sorry all - catching up on this thread now...  On Mon, Nov 25, 2013 at 2:27 PM, Paul Knight < paul.knight@oasis-open.org > wrote: I'll look over the doc in a bit... Regarding acknowledgments, most TCs list all members, rather than trying to figure out who "contributed"...  any member can ask to be listed or excluded, as well. On Mon, Nov 25, 2013 at 2:11 PM, Michael S. Tsirkin < mst@redhat.com > wrote: On Mon, Nov 25, 2013 at 10:22:19AM -0500, Paul Knight wrote: > Hi all, > > I'm glad to see that the TC has settled on using LaTeX to produce the Virtio > specification. > > The HTML and PDF versions look like they are on the right track, but will need > to have a number of adjustments to match the publication formats used for OASIS > Work Products (as opposed to the "working draft" formats, which omit several > elements which are pretty tricky).   > > Since (by using LaTeX) you will be handling every aspect of producing the PDF > and HTML files, you'll need a complete example of the expected front pages. >  That is in the attached ZIP file. > > Assuming you want to have a formal Public Review when you publish the first > Committee Specification Draft, you will actually need to produce TWO parallel > sets of files: > - Committee Specification Draft 01 (csd01) > - Committee Specification Public Review Draft 01 (csprd01) > > In the attached ZIP file, I've included examples of the expected publishable > csd01 front pages (in HTML, PDF, and source DOC formats), the publishable > csprd01 front pages (DOC only), and our internal checklist of changes from > csd01 to csprd01. > > You'll need to follow these front page formats exactly as you prepare the > documents for publication. > Chet and I are very happy to review your planned materials before you submit > them.  Our experience has been that it takes a few iterations to get everything > completely ready, especially for the first (csd01/csprd01) publication. > > Best regards, > Paul OK here's a draft csd for starters, will do csprd01 draft when we are happy with the csd. We still need to fill in the following gaps (for both):  - fill in conformance section. Need help from others on this one  - fix MUST/SHOULD etc to must/should for consistency  - fill in acknowledgements for non-editors who contributed  - update procedure on allocating device ids Need feedback from others on this. Paul - anything else that's a must that I missed for CSD? Thanks! -- MST -- Paul Knight   - Tel: +1 781-861-1013 OASIS - Advancing open standards for the information society Document Process Analyst -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393   Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393  Check your work using the Support Request Submission Checklist at  http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html   TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open

On Sun, 2013-11-17 at 13:18 +0000, Michael S. Tsirkin wrote: > The result is very close to one produced by exporting from the > ODF we were supplied, with the exception of the TOC formatting, > where section numbers are in blue instead of black, and major > sections don't have dots leading to page numbers. I can commit to fixing such stuff. It's usually just a matter of a magic configuration value for a package (hyperref in this case)... Pawel

On Mon, Nov 18, 2013 at 03:13:35PM +0000, Pawel Moll wrote: > On Sun, 2013-11-17 at 13:18 +0000, Michael S. Tsirkin wrote: > > The result is very close to one produced by exporting from the > > ODF we were supplied, with the exception of the TOC formatting, > > where section numbers are in blue instead of black, and major > > sections don't have dots leading to page numbers. > > I can commit to fixing such stuff. It's usually just a matter of a magic > configuration value for a package (hyperref in this case)... > > Pawel > Cool. Want to do this on top of my tree and send a patch?