Re: [tag] Re: Done - Re: Ready to start next, potential candidate drafts

[Stephen Green <stephen.green@documentengineeringservices.com>]

Sorry, I see now the main comment which would
affect implementations is the last about report. I
guess there is case for agreeing this before a vote

Best regards

Steve
---
Stephen D Green




2010/1/19 Stephen Green <stephen.green@documentengineeringservices.com>:
> Hi Kevin
>
> Welcome back
>
>>
>> I had some comments questions on the model. Probably some of these things
>> should be considered before voting a draft.
>
>
> I'm not sure your comments would need
> any halt on going to CD since they seem
> to relate just to the text of the specs and
> not substantively to the implementations.
>
>
>> 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.
>>
>
>
> This at first glance might have normative,
> substantive implications but I'm not sure
> it does since it is always possible to have
> empty elements: Even if you mandate that
>
> <normativeSource/>
>
> is invalid, which is difficult to do and even
> more difficult to enforce in an instance,
>
> <normativeSource>.</normativeSource>
>
> would still be valid but just as irksome.
>
> I would suggest we are best leaving this to
> best practise and the guidelines rather than
> to implementations which cannot really
> enforce it (not without unreasonable cost in
> complexity of the implementation, eg it is
> difficult to go through an instance removing
> or flagging all empty elements). If you want
> to specify a normativeSource either implicitly
> or in some other way such as in an outer
> testAssertionSet as a shared value then it is
> unreasonable to have the spec requirements
> prevent this. So it seems to me. In other
> words I'd think we could put this and your
> other comments as points for improvement
> (we have discussed setting up Jira for this)
> along with public review comments in a
> further set of documents after the review and
> still go through with a vote.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/19 Kevin Looney <Kevin.T.Looney@sun.com>:
>> 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
>>>
>>>
>>
>>
>