Following up on my action item to give feedback on my DR Log V2 Plan

[MURATA Makoto (FAMILY Given)]

Dear colleagues,

Here is my proposal.  I strongly advocate the use of Assembla.

1. Problems of the current approach

1.1 Schema maintenance problems

1) Different specfications (e.g., FPDAM1 and DCOR1) developed 
   in parallel share a single set of schemas.  What happens if 
   one of them is disapproved?

2) WG4 members cannot obtain schema files and point out problems 
   (including syntactical errors) before schemas
   are generated from change-tracked Word files.

3) RELAX NG schemas cannot be created before XSD schemas are 
   generated from change-tracked Word files.

1.2 DR maintenance problems

1) The DR Log file is bulky and cumbersome.

2) The task of maintaining the DR Log is a too siginifant 
   burden on the project editor(s), and thus the the DR Log 
   does not always contain all the relevant e-mails or attachment files.

3) Maitaining the consistency between the DR index (as an Excel file) 
   and the DR Log is also a siginifant burden on the project editor(s).

4) Statistics are published only occasionally (by hand), and they are
   not very flexible.  For example, we cannot count the number of 
   MIME-related DRs.

1.3 DR submission problems

When we developed the web form for submitting DRs, we thought that
this will become by far the most important channel.  Apparently, it is
not.  Since some editorial defects are best described as changes in
the DOCX file rather than filling out flat-text-only forms, some
member bodies continue to use DOCX files for submitting DRs.  The web
form does not cause any troubles, however.

2. My proposal

The proposal by Rex addresses 1), 3) and 4) in 1.2.  However, 
the other problems are not solved.  I would like to provide 
some additions and changes to the proposed plan.

I would like to advocate the use of Assembla.  In particular,
subversion can easily addresses 1), 2), and 3) in 1.1.

2.1 Schema maintenance

Schemas should be maintained in the subversion repository of Assembla
rather than changed-tracked MS-Word documents.

Schema files can be accessed via the web-based user interface of
Assembla, but schema experts and the project editor will require
front-end sytems (such as Tortoise) for schema authoring.

- For each specification (AM or DCOR), we create a subversion
  branch.  This branch contains those schema changes required for the
  amendment or DCOR.  Note that different specifications developed in
  parallel have different schemas.

- Whenever a WG4 member proposes a schema change in reply to a DR,
  that member should store the change into the subversion repository,
  and should create a link to the DR at the same time.  This 
  action requires understanding of subversion and the front end system.

- Everybody can view schemas stored in the Assembla subversion 
  repository at any time.

An issue in the subversion approach (which maintains schema files
only) is the creation of changed-tracked Word files.  I believe that
this issue can be addressed by using Word for comparing two DOCX
documents.

- Create a DOCX document containg old schemas.

- Create another DOCX document containing new schemas for the 
  speficiation in question.

- Use the file comparison feature of MS Word for generating change-
  tracked DOCX documents.

- Incorporaate the change-tracked DOCX documents as part of the 
  (F)PDAM or DCOR.

2.2 DR maintenance

Although I strongly advocate the use of Assembla, we should 
not force the project editor to use the web-based user interface 
of Assembla for DR maintenance.   This is because he might 
not be always able to access Assembla and also because MS Office
is sometimes more convenient than web-based user interfaces.

- For each DR, the project editor creates a DR file as a DOCX document, 
  as proposed by Rex.  Whenever the status of the DR changes, the 
  project editor revise the DR file.

- The project editor uses a program for automatically creating an
  Assembla ticket from the DR file.  Custom xml or smart tags embedded
  in the DR file allow data to be easily extracted.  The program also 
  store the DR file as an attachment file in Assembla.

- The project editor uses another program for creating the DR Log
  Index from the Assembla tickets (not from the DR files) as an XLSX
  document.  Links from the DR Log Index to DR files use the URI of
  the Assembla repository as a base URI.  The DR Log Index also 
  contains the summaries and statistics on a new Sheet.

- The project editor then stores the DR Log Index in three formats, 
  namely XLSX, TSV, and PDF, as attachment files, and create links from
  the Assembla wiki.

- Each WG4 member receives a notification mail for each newly-created DR.

- WG4 members discuss about each DR by using the comment feature of 
  Assembla.  All comments on DRs are stored in the Assembla
  repository, and are accessible via the web-based Assembla user 
  interface.  Attachment files are also stored in Assembla.

- If necessary, we develop a program for generating a single file (zip? pdf?)
  for each DR or all DRs.  This program would help those who do not always 
  have access to the Internet.

- As described in 2.1, schema changes required for any DR should be
  stored in the Assembla subversion repository, and ech commit action 
  should provide a link to the relevant DR.  Such links make it easy 
  to maintain the relationship between schema changes and DRs.

The project editor will be freed from two works.

- He does not have to copy all e-mails and attachment files to DR Log files.

- He does not have to maintain the DR Log and the DR Log Index 
  in sync.


Note: I do not have an opinion about the DR history log.  Is it hart
to maintain?  I have almost never read the DR history log.
  
2.3 Milestones

Whenever a new amendment project is created, we create an Assembla
milestone and a branch in the subversion repository.  Whenever we
start to create a DCOR, we do the same thing.



Regards,

SC34/WG4 Convenor
MURATA Makoto (FAMILY Given)