minutes from 5 Feb 2004

[Anne Hendry <anne.hendry@sun.com>]

The Tools and Techniques Subcommittee will meet on 5 February 2004 16:00 UTC (8 am Calif, midnight Singapore)
http://www.timeanddate.com/worldclock/fixedtime.html?day5&month=2&year=2004&hour=16&min=0&sec=0&p1=0

#####################################################
STANDING INFORMATION FOR UBL CONFERENCE CALLS
U.S. domestic toll-free number: (866)839-8145
Int. access/caller paid number: (865)524-6352
Access code: 5705229
#####################################################

Agenda:

Sue, Ray, Anne, Tony, Stephen, Ken.

1. Welcome from Chair, Roll, Minutes, Agenda

   - New members

   - joint isc work

     Yes, and possibly with FPSC too?
     There should be far fewer subcommittees.
     Next set of scs should be based on our next set of objectives.


2. Contniued review/work on TTSC paper put forward by Chris
   
   - see mail from January 26 and forward, and attached template
   - work on and assign content blocks
     - Document naming/title/oasis templating, etc (Anne)
     - code list integration (update on lcsc and clsc status and Tony's work)
     - Use cases (Chris/Ray/Anne)
     - Tools descriptions (Stephen/Michael?)

Document review:

Section 4 (dev environemnt)

Ray: look at tools in two ways: either historical for production,
or looking forward.  Tools used for standard, or tools afterward
for posterity.  A: see looking forward.  Sue: lessons learned.
Ray but be clear about which we are talking - tools used to product.

Ray2: development env specific to software.  here probably better
to describe conditions under which it is being developed.  Bob at
UC has one, Michael has another.  Is this refering to condidtions
under which ubl was developed, not referring a kind of app software.

1) is this for ubl dev or ubl use?
described env in which ubl was deloped, conditions faced
A: tools used for creating ubl, softare used for ubl
R: not sure there is an environment
Sue: not until there's customization.

R: Use secton 8 for future use suggestion

sue: customization is separate (almost appendix?)
R: commercial community will come up with tools

R: value of paper is in the description of what people can do to
continue immediately, so talk here about how ubl was produced
and how it can be used.

Separating a third category now - what would we recommend people
to use for ubl.  Even if there is no customization, people still
will need tools for hings like schema validation, styleshets, formatting.
So there should be a practical section on advice on what to use for
implmeention tools. to help people jump start.  This helps adoption
as well.

Fourth category - not just customization, but just plain schema work.
This was out of scope.  eg. haven't used rational, haven't limited
ourselves to proprietary, free, etc.  not just open standards,
but open tools.  In black and white that ubl is royalty free and
non-funded. put this right at the beginning.  Point out tht the
reason we used some tools is that they were given to us (xmlspy,
edifix, ublish, etc).  Highlight that peole don't have to spend
money on using ubl.

There should be a tools goals section for tools adoption, development
and use, talking about how we tried to keep things free - coulnd't
sometimes, but tried, to lower the barrier of use.

**** Title becomes tools for devleoment and use of ubl.

sue: But after ubl is released it will be different and need to
capture how tools can be used then.  A: Yes, and even part-way through ubl,
poeple developed tools that are not free.

St: so we can say that 1/2 through it was pretty much all free.
scripting, etc, freely done.  not sold for free, but can be gotten
for free.  so we've tended to use things that are free and will be free
for others, so that while we have things in place now that are free but
not necessarily free for others, but people can still use our methodology
for free/cheap.
R: so imagining this to be an enumeration of the tools that were chosen
(a,b,c,d,e,f); this is how the progression went, that's how things were done.

Sue: but that's where the market has come in, so don't be afraid to
say this - people ge what yoou're paid for.

St: always tried to consider those that do not have rsoruces,
so chose tools and methodology that is cheap or free to adtop or use.
don't expect people have to keep to that.

sue: But this is not enceaarily always in their best interst.

A: sue will write the chapter on 'looking forward' about what we can
see coming up in the way of tools - what they can do for you, how
they may be integrated, the value that they have as along-term investment.


R: We need another section that talks about standards dependencies
how we used them and why (both tools and standadrds). as a developer,
I'd want to have list of tools and standards.
A: We currently have this in appendix A of beta doc.
St: should add xslt

Sue: what about adobe
St: yes, there are other software providers whose tools we have used
by virtue of the fact that they have freely donated those for our use.
and we can say that we expect to keep the standard open,frree, cheap,
it will be advantageous for other software providers to incorporate,
their tools for use by others, but cheaply.  for instance, OO, etc.
R: one factor is ease of use of specification.
Sue: well, also because it's hard to align.
St: should be a paragraph on this - it's the concept behind ubl to keep
things simple for gov.  absolutely bottom line in terms of gove (cost).

Sue: one range of tools we haven'et worked with yet - mapping software
that enables people to map from ubl in and out of other standards.
St: reference this in the current section, because neeed to map from
ubl to versions of instances (used stylesheets)
sue: yes, also use edifix.
st: if it can be used by other open orgs and doesn't charge royalties,
then it's really open.
R: Take an applied approach; the actual sofware deveopers want actionable
items here quickly.  so make this an enumeration of tools and this is
our expeirnce and sequence of steps and theese are ths tatndards that
are used.
A: describes scope at hand, but map of landscape and what happens
st: and has to be that we don't force people downe a path only beause
people wil get paid for it.

2) schedma generateion (section 5)
st: Peole have to go over and above call of duty to use ndrs and turn
them into someting usable.  we'ver relied n others to do this.  this is
typically a specialist task and we've done it so other people don't have to.
if they want to follow what wev'e done to create their own schemas,
following ndr rules, rule are guidelines for anyone generating schemas.
This is sprecifically talking about how we to to where we are.
if eple try to do what we've done they'll find this part is difficult.
not assuming why they want to do this, they just do. if you want to create
schemas from the ss or whatever, will find you'll need design rules because
xs schemas must be designed and generated acoording to a design.  our desing
is optimized for interop.  if poeple wish to use what we have, to do the
same thing, will need specialized tools/skills.  These would be other
standards bodies or people creating other standadrs of their org.
Talking about , ie, xbrl, looking at what we've done and learn from it.
peoel who are trying to copy ubl, like Bob is trying toteach people how
ubl is generated so they can go away an degenerate in a fashion.

A: Tools section is to show why the sehmeas are how they are,
but also to give pele the benefit of our experience.
St: so we should help people understand how we avoided pitfalls in this this area.
eg1. we insisted on automatic generation rather than handcraft to avoid typos,
eg2. SUe: ss created typos - so put formulas in ss to avoid this.
tighetn up ss as much as possible 
eg 3. sometimes blanks in ss
st: ( + and - ) have beneifted from being able to change ndrs continuously.
have been able to chage tools as we go.

AI: stephen current pracice issues
AI: Sue - looking forward tools

A: where to talk about ndrs?  st: schema cahpter.

Done with normative shcemas.

chapter 6 : non-normative comonents

conceptua models – leave it out – for lcsc to define; were done by hand
conceptual model came from xbrl; need to capture in the lcsc methodology.
St: but tools, such as not useing RR. Sue: did use RR for conceptual model.
Section wouldn't be complete without mentioning the conceptual model.

     - incorporating info from Beta

3. UBL 1.0 schema generation

   - issues
     - data types and code lists?
   - validation
   - 

   Links:
  
   - Tool description and download info
     http://lists.oasis-open.org/archives/ubl-ttsc/200312/msg00001.html

   - Work-in-progress documentation format for discussion/feedback
     http://www.gefeg.com/public/ubl-10-beta/index.htm

4. Deliverables and schedule

5. Other business

   - volunteer to run the 12 February meeting

6. Next Meeting

   12 February 2004, same time, call info.