Subject: [TOOLS-DEVELOPMENT] Notes: Tools Call 15 December 2010

From: Steve Conte <[email-masked]>
Date: Wed, 15 Dec 2010 08:49:27 -0800

As always, all mistakes are my own

-----
IETF Tools Call - 15 December 2010

Attendees:

Ray Pelletier
Julian Reschke
Steve Conte
Robert Sparks
Tony Hansen
Henrik Lebkowetz
Bob Hinden
Ron Bonica
Glen Barney
Karen 

Agenda

1.  2010 IT Project Update

RP: items 1-12 have been completed.  10 projects in work, 3 of them are expected
to close this year (13-15).  Remaining projects are in work and started in 2010 but
will continue into 2011.  Asking IDIQ Developers to prepare proposal for 
xml2nroff in python 

for 2011
8 datatracker projects
secretariat and community projects
rfc services projects

budget is USD$429K for 2011

2.  xml2rfc

discussion:
Python is chosen for a variety of reasons:
- pre-qualified developers via IDIQ
- tools already in python
- etc

Drop in replacement.  People who are currently using xml2rfc can use the new 
xml2rfc.

Some people may have to make changes to their code to use new xml2rfc

requirements may not be comprehensive?

how much nroff is being generated?

should new work go through the step of generating nroff or will it be better to tweak
language so that rfc-editor can use xml2rfc without nroff

if we don't use nroff as intermidate format, then a much larger tool will need to be 
built.

nroff that rfc-ed uses, is really only a subset of the tool

people have been writing drafts using nroff for years
xml2rfc uses a simple nroff
if we find one particular thing that nroff won't do, we can do whats being done today
don't try to repeat work thats already been done

are you expecting people to download the new xml2rfc to local client and run it locally
rather than using the web interface ---  If they want to, will require python and nroff

must be available both hosted and local

goal is to move tool so it's supportable, is not the end of development or discussion

hasn't gone to developers for proposals yet, so will bring to committee and flush out
the SoW to be more definitive

3.  Beijing Sprint Results

HL: accomplished more in Beijing than previously
	some people working on same code, which led to change collisions.  worked out how to 
	address this
RjS: had a critical mass of people show up with dev env working already
	 had been continuing developing from previous sprints
	 more rapid ramp up to do actual coding
	 evidence of people continuing to work on the code since Beijing.  So community 
	 is starting to stay active between events

4.  Prague Tools Plans - Sprint, IT projects, Training

RjS: no plans yet.  Setting goals, will follow pattern from most recent sprint
     same kind of space would be appropriate
     same kind of network (wired is good)
     food access control issues.. food may be in another location in future
     likes having the sprint in the terminal room
HL:  no plans yet.  converting issues to trac items prior will make it easier for 
     next sprint.
RjS: as tools are coming into sprint, volunteers can do testing on them.  That didn't 
     really happen at last sprint.  If we want to do this for future sprints, we should
     identify what we'll do and formally document actions/goals
RP:  will have a fair amount of work that will be approaching readiness by Prague that 
     could use volunteers for testing.  Russ asking Chairs to shake them out to report
     for chairs luncheon on the wednesday

5.  Other

HL: need to have a discussion regarding the way secretariat admin tools may be forcing
    AMSL to require more work to get them in place than necessary
RjS: would like to get an overview update on database migration schema change
HL:  IOLA did a study (almost completed one main view) and are now continuing importing
     to make view work well.  This will be the major item of code conversion
     They are actively interfacing with Henrik
	 Within weeks, should have a fully function document view that uses the new tables

-----
Steve Conte
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Dec 2010 20:26:03 +0100

Hi there,

I'd like to elaborate on the xml2rfc discussion.

 From that I hear the SoW will *only* contain the NROFF output. Not 
formatted text, as it can be produced from the NROFF, and not HTML, 
because we already have a maintained implementation for that (thanks!).

There's a problem with this plan.

The development of the xml2rfc (RFC2629) vocabulary has been slow 
(actually has come to a halt) because the *important* implementation 
(the one needed for submitting IDs and publishing RFCs) essentially was 
unmaintained (except for emergency fixes).

The plan as I currently understand it will get us into a similar 
position; we may end up with an alternate implementation for NROFF, for 
which there will be no ongoing development, unless I'm mistaken.

Also, taking out 2 out of 3 formatting targets, with plain formatted 
text being the tricky one, somewhat changes the picture with respect to 
how we could re-use what we have. The XSLT code already understands the 
vocabulary, references, lists, the boilerplate issues etc. Replicating 
*that* functionality into a different language for the sake of just 
producing NROFF seems like a bad idea; it would be much smarter to just 
build on top of the existing code, adding a new target format. In 
*particular* if the plan is to rely on that code for HTML generation anyway.

With the existing XSLT code, producing NROFF could be done either with a 
different "backend" (I have one for NROFF that I abandoned a few years 
ago), or by converting the XHTML-as-generated to NROFF. That would save 
us from replicating all the high level logic again.

That being said: the current xml2rfc code does *not* use NROFF features 
to produce the TOC, the index, and tables. Those are tricky. If somebody 
with NROFF know-how is willing to assist me, I can into resurrecting the 
XSLT-based code for NROFF production.

But let's please try to avoid re-inventing the wheel, causing 
double-maintenance, and confusion about how to evolve the vocabulary.

Best regards, Julian