[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Re: Done - Re: Ready to start next,potential candidate drafts
Hi Stephen and everyone,
Sorry I haven't had much chance to participate (I think I was last
calling in when we voted to separate the model from the guideline). My
apologies for bringing my comments in late
I had some comments questions on the model. Probably some of these
things should be considered before voting a draft.
=========================================================
1.) Page 6, Section "Normative Statement, ..."
Uses a term "Conformance Target" - is this sufficiently defined? I
don't see definition or reference to it elsewhere.
2.) Page 10, Implicit Test Assertion Parts
I think the idea of using implicit values is good, especially for things
like Test Assertion Target (where the Target may be the entire spec).
How are the implicit parts qualified? Would there be some kind of
conformance statement that says something like "when Target is not
specified, assume the testing target is the entire spec"?
3.) Page 11, Convention Used for Formally Defining the Model
This first paragraph looks like a duplicate of section 1.1 (page
5). Can this be removed, or shortened to say something like "refer to
section 1.1 in regards to the overloading of "class" and "attribute"
4.) Also page 7
I find the (x..y) notation rather curious. It looks semantically
similar to elements of Regular expressions (such as '*' and '+'). Why
aren't we using Regular Expression notation?
5.) Pages 13 - 30
Probably this is because all structures are related to a direct
implementation in the style-sheets/schema.
Almost all of these structures have elements which are purely optional
(eg. '(0..1)') The problem is this means that it is completely valid to
have empty structures. That is, it is OK to have (for example):
normativeSource { }
There probably should be some kind of nomenclature that prevents this.
6.) page 19, report
'Report' was a new element for me, I had not seen this before. It's
definition is pretty vague, and I'm wondering if it is too
implementation specific (eg. describing how TAs should be reported by
some tool, not part of this specification).
=========================================================
On 1/7/10 1:07 PM, Stephen Green wrote:
> I'm all for starting a ballot (at some point, as Dennis says)
> based on these last posted drafts (not further changes)
> - unless of course anyone in the TC has requests for further
> changes first (e.g. if even at this stage we wanted to ask
> Dmitry to look over them and we made changes as a result
> - as per my AI for the Jan 5th meeting - though this would
> put back our schedule so I'm not sure now).
>
> As the minutes just posted say though we did make a
> decision on 5th Jan to aim for a set of drafts for this by 18th
> - but if there were agreement generally to actually start a
> ballot on 18th based on the drafts just posted here
> http://lists.oasis-open.org/archives/tag/201001/msg00054.html
> I'd kind of be in favour too - but we do need to give everyone
> voting (and those not voting too) enough time to review them.
>
> By getting drafts out already, I think it gives us time to make
> changes before the ballot, but with the consideration that this
> then shortens the time for reviewing the final version before
> the ballot and also adds to the workload of sorting between
> several draft versions. Ideally we'd want these drafts to be OK
> for ballot and have plenty of time before a ballot to review them
> while freezing them (as Dennis suggests).
>
> I'm not really in favour of separate public reviews though. I get
> the impression that related specs are supposed to be put out
> together (though we could argue that they are actually distinct).
> There are dependencies which mean that a change to one
> requires a change to the others (e.g. a change to the markup
> requires a change to the guidelines and maybe to the model).
> We could get into a mix-up if we had review of one spec then
> agreed it but a subsequent review of another spec required us
> to go back and change the first. Better, I think, if we can
> respond to any comments on either document by changing
> potentially all of the documents at the same time following a
> simultaneous public review.
>
> Even if we didn't have all our members with voting rights at the
> time of a ballot I'm sure we would accommodate the expression
> of approval (or otherwise) from those who would normally vote
> but might not be able to vote officially - an unofficial vote or just
> a statement of agreement on the list would be valuable all the
> same. As of course would participation in internal TC review
> which is fine even for non-voting members.
>
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/7 Dennis E. Hamilton<dennis.hamilton@acm.org>:
>
>> Sorry to go all parliamentary on this, but this is serious business and we
>> must be careful to demonstrate that we are deliberate and thorough. Also, I
>> am not sure what a candidate draft is a candidate for. We need to be more
>> clear. I assume Stephen means specific working drafts that are proposed for
>> balloting for acceptance as Committee Drafts (and as Public Review Drafts if
>> concurrent approval for that is included in a single ballot).
>>
>> I'm concerned that we are rushing more than necessary to have the stages
>> work. (If we are laboring under a strict deadline, I am not aware of it.)
>>
>> Let's look at this in terms of deliberate stages that are needed to get to
>> Public Review.
>>
>> A. I think there are three steps:
>>
>> 1. Approval of the three documents as Committee Drafts.
>>
>> 2. Approval of the three Committee Drafts for Public Review.
>>
>> 3. Submission of the Public Review Drafts to the TC Administrator for
>> conducting the 60-day public review.
>>
>> B. We can do (1-2) concurrently. However, for the first try, I recommend
>> decoupling them and doing them sequentially. If we need to recycle after
>> (1), with new proposed CDs, that re-proposal can be with a combined (1-2)
>> ballot. I against having the working documents that go into (1) be already
>> identified as (new) committee drafts. The update to a CD number should only
>> happen after CD approval of a working document (including a working draft
>> that is a revision of a previous CD). Having more than one document around
>> that claims to be CDxx makes for craziness. We just did that at the ODF TC
>> and it was awkward.
>>
>> C. I recommend that every (1) and (2) (or 1-2 together) be by electronic
>> ballot. That means it runs a minimum of time and it might as well run to
>> end just before the next scheduled call that is far enough into the future
>> to satisfy the minimum. Then we can use that call to decide whether to go
>> to the next step or make necessary comment-responsive changes and recycle.
>>
>> D. We need the documents to stand still during these ballots and public
>> reviews too. We can collect comments but the only documents being commented
>> on should be the ones under ballot or in public review. No new
>> working/updated drafts should be posted until after the end of a ballot.
>> Otherwise things go too random.
>>
>> E. KEY POINT: The electronic ballot forces us to identify who the eligible
>> voting members are at the start of that ballot. It also causes visible
>> notifications, reminders, and encourages the attention of folks, including
>> those who have not maintained their Voting Member status.
>> If we start an electronic ballot right now, it will be who the voting
>> members were after the completion of the last TC call. I think there are
>> only 3-5 of us, depending who was on the last two calls in 2009 as well as
>> the January 5 call. I *think* (1) and (2) require full majority approval.
>> Please don't take my word for it.
>> I'm not sure we can start an electronic ballot now if we don't have a
>> standing rule that allows for initiating them at other than a TC call. The
>> TC Procedures need to be checked for that.
>> If not, we can vote to start the electronic ballot on the January 19
>> call.
>> If motions for electronic ballots can be done on the list in accordance
>> with TC Procedures, we can do that and, I think, run a ballot that ends on
>> January 18. We should do that quickly, in that case.
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
>> Of Stephen Green
>> http://lists.oasis-open.org/archives/tag/201001/msg00031.html
>> Sent: Thursday, January 07, 2010 07:33
>> To: TAG TC
>> Subject: [tag] Re: Done - Re: Ready to start next, potential candidate
>> drafts
>>
>> Following TC Admin approval of the namespace in the
>> schema
>> http://lists.oasis-open.org/archives/tag/201001/msg00029.html
>> I believe we can proceed with these drafts, if the TC agrees,
>> and treat these drafts as candidates for a ballot. Unless
>> anyone has anything they think we still need to change.
>> I think it was agreed at the last TC meeting we would aim
>> to have the candidate drafts agreed by next Tuesday (12th Jan),
>> though perhaps we can agree them sooner than that. (Not
>> yet the ballot of course, just approval of drafts to proceed
>> with to a ballot.)
>>
>> Best regards
>>
>> Steve
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2010/1/6 Stephen Green<stephen.green@documentengineeringservices.com>:
>> http://lists.oasis-open.org/archives/tag/201001/msg00020.html
>>
>>> Done...
>>>
>>>
>>> guidelines:
>>>
>>>
>> http://www.oasis-open.org/committees/download.php/35805/testassertionsguidel
>> ines-draft-1-0-9-3.pdf
>>
>>> model spec:
>>>
>>>
>> http://www.oasis-open.org/committees/download.php/35806/testassertionsmodel-
>> draft-1-0-1.pdf
>>
>>> markup spec:
>>>
>>>
>> http://www.oasis-open.org/committees/download.php/35801/testassertionmarkupl
>> anguage-draft-1-0-2.pdf
>>
>>> markup schema:
>>>
>>>
>> http://www.oasis-open.org/committees/download.php/35803/testAssertionMarkupL
>> anguage-draft-1-0-2.xsd
>>
>>> markup namespace document:
>>>
>>>
>> http://www.oasis-open.org/committees/download.php/35796/testassertionmarkupl
>> anguage-1.0-namespaceDocument.zip
>>
>>>
>>> [I hope the above could be candidates for balloting towards committee
>>>
>> draft
>>
>>> and public review.]
>>>
>>> ----
>>>
>>> markup examples updated with new, OASIS-guided namespace
>>>
>>>
>> http://www.oasis-open.org/committees/download.php/35808/ubl-ta-draft-1-0-2.x
>> ml
>>
>>>
>> http://www.oasis-open.org/committees/download.php/35809/widgetTAExample-1-0-
>> 2.xml
>>
>>>
>>> Best regards
>>>
>>> Steve
>>> ---
>>> Stephen D Green
>>>
>>>
>>>
>>>
>>> 2010/1/6 Stephen Green<stephen.green@documentengineeringservices.com>:
>>>
>>>>> I will possibly send extracts of proposed text for your
>>>>> consideration prior to updating the drafts so we can do this
>>>>> all with just one iteration of the three documents.
>>>>>
>>>> As it happens, I think I have been able to update the drafts
>>>> without any likely further issues. I will send drafts shortly
>>>> which I hope might be acceptable as candidates for ballot
>>>> moving towards committee draft status, and public review.
>>>>
>>>> Of course, that is best case scenario: Not-so-best case is
>>>> that there is plenty of time still before the end of the week
>>>> for me to respond to any issues and send another set of
>>>> drafts if need be. Please let me know soon if I should do so
>>>> (by the weekend ideally).
>>>>
>>>> The markup drafts which I hope can be candidate drafts were
>>>> uploaded earlier today -
>>>> schema: http://lists.oasis-open.org/archives/tag/201001/msg00012.html
>>>> spec: http://lists.oasis-open.org/archives/tag/201001/msg00011.html
>>>> [There is a very minor error in the spec in that I have put the
>>>> year 2009 (should be 2010) in the reference to the model spec.
>>>> I hope I can correct that later.]
>>>>
>>>> Best regards
>>>>
>>>> Steve
>>>> ---
>>>> Stephen D Green
>>>>
>>>>
>>>>
>>>>
>>>> 2010/1/6 Stephen Green<stephen.green@documentengineeringservices.com>:
>>>>
>>>>> If we are all agreed on my last two emails
>>>>>
>>>>> http://lists.oasis-open.org/archives/tag/201001/msg00003.html
>>>>> http://lists.oasis-open.org/archives/tag/201001/msg00004.html
>>>>>
>>>>> resolving the only outstanding issues, I believe
>>>>> I can start work on the next iteration (potentially candidate drafts).
>>>>>
>>>>> I will possibly send extracts of proposed text for your
>>>>> consideration prior to updating the drafts so we can do this
>>>>> all with just one iteration of the three documents.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Steve
>>>>> ---
>>>>> Stephen D Green
>>>>>
>>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]