RE: [uiml] Schedule of items to be completed before voting ontheCommittee Specification

["James Helms" <jhelms@harmonia.com>]

Thanks for all the excellent feedback!  I will add both of your items to
my schedule of remaining tasks.

Responses in <JIM> tags below...

Thanks,

James Helms

Director of Research and Development
Harmonia, Inc. 
P.O. Box 11282
Blacksburg, VA 24062

Office: (540) 951-5900 x 205
Cell: (540) 558-9722



-----Original Message-----
From: Kris Luyten [mailto:kris.luyten@uhasselt.be] 
Sent: Wednesday, February 28, 2007 9:56 AM
To: Robbie Schaefer
Cc: uiml@lists.oasis-open.org; Jo Vermeulen
Subject: Re: [uiml] Schedule of items to be completed before voting
ontheCommittee Specification

On Wed, 2007-02-28 at 15:50 +0100, Robbie Schaefer wrote:
> Hi,
> 
> > More organizational stuff:
> 
> Below my personal opinion. What does the rest of the TC think?
> 
> > - Is there really sufficient difference (or progress) w.r.t. the 3.0

> > specification to have a 4.0 specification? (don't want to start a 
> > riot here, just to make sure there is a good motivation for doing
this).
> 
> I think so, additional to minor changes we introduced three major 
> modifications (layout, variables with arithmetic, template parameters)

> which resulted in about 10 new elements and has effects on most 
> elements of the specification.
>

<JIM> I agree with Robbie.  We have increased the number of tags in the
language by about 25% (depending on how you look at it), and increased
the complexity of the language several fold :). Don't misunderstand me,
I think the additional flexibility provided is very useful and the
additions are well received. </JIM>

 
> > - Can we split up the document, e.g. like the GRDDL specification 
> > does
> > it:
> >  => Specification Document (Metamodel, Namespaces, Schema and DTD 
> > stuff, explanation for each element, mainly suitable for 
> > implementers of UIML renderers and translators, but also for UIML 
> > users to get to know the details)  => Use Case Document (cases that 
> > cover the whole specification, with examples, suitable for testing 
> > UIML renderers and translators but also for UIML users)  => Primer 
> > document  (introduction document to the technology, links to 
> > implementation, suitable for UIML users)
> 
> Would be very nice to have, but this would probably delay the 
> completion of the standard.

Actually, I suggested this so we can complete the standard sooner: the
specification document contains the actual standard and should be less
in volume since the other two documents complement it with additional
materials now (extensive examples, implementation details etc.).

<JIM> Kris, could you describe how you think it will speed the process?
My first thought mirrored Robbie's...  Would the specification document
hold basically no examples?  Instead they would be contained in the
separate use case docs?  I think I see how the divisions would work, but
would like to make sure I understand correctly?  Maybe you could provide
a brief outline of each document to give us a better idea of the
content?</JIM> 

> >> I have found several small points for improvement/corrections in 
> >> the document. How should we proceed?
> >> Should all the TC-members edit with "track changes" on in parallel 
> >> and James tries to update the input he gets or should we pass the 
> >> document as a token sequentially?
> >
> > Can we do it in the Wiki?
> 
> You did not know the pains I suffered to get the stuff into the Wiki 
> and the pains James suffered to reconstruct the specification from the

> Wiki again ;-) So as much as I usually like collaborating through a 
> Wiki, in this case I am against it.

OK, I was not aware of these difficulties. 

<JIM> Yes, unfortunately with the version of MoinMoin Wiki they use,
entering and extracting the document was a long arduous exercise in cut
and paste. Going back to Robbie's original question, I think the fastest
thing would be for people to edit the documents with change tracking on
and let me merge them as they come in.  That way we could be working
parallel.</JIM>