OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [tm-pubsubj] Call for vote on new deliverable structure



* Bernard Vatant
| 
| <motion>
| 
| The first TC deliverable will be called :
| "Published Subjects : General Requirements and Recommendations"

I haven't had time to look into this yet, but could you explain why
you would like to split this deliverable out from the original first
deliverable?

To me it sounds as though the first deliverable will contain very
little in the way of real substance, but that it will imply that we
know what to do in the second deliverable. If we publish deliverable
#1 first, that implies to me that we can't go back and change it. So
we shouldn't freeze it before we know what we'll do in deliverable
#2. But if we *do* know what to do in deliverable #2 why don't we just
do that at the same time?

On the other hand, I don't see why we can't just produce a new draft
of the recommendations that contains what's now described as
deliverable #1, and then continue work on adding what is now described
as #2 to that draft. That will avoid any procedural problems with
going back and changing #1, and still allow us to set down what we
feel we have figured out so far.

I don't see the point of this proposal.  Several times already I've
seen people look at the current recommendations and be disappointed
because there is so little there.  Now we seem to have decided that
the first deliverable is to contain almost nothing, and I don't think
that's a good idea.

I think that we are very close to ready to move on from the basic
principles that were agreed on in Barcelona and start on the real
work, which is now scheduled to be deliverable #2. I fear that if we
follow the proposed schedule we will

 a) cause problems for ourselves by freezing a document containing
    recommendations we don't understand the full implications of, and

 b) cause more problems for ourselves by getting bogged down in the
    practicalities of finishing and polishing that document, rather
    than moving forward to the real issues and actually making real
    progress. 

So at first glance I don't like this proposal at all. Maybe my
misgivings are exaggerated, but I can't see any reason to do this, and
several reasons not to.

Also, Bernard, it would be very good to get more than 2 days warning
before a vote starts. I haven't had time to read all my email properly
the last days because of various forms of non-TC-related stress. More
time would have helped us avoid mixing up discussion and voting. (If
we are required to vote rather than discuss at this point I guess this
counts as a very long-winded "NO".)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC