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

[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
>>
>>
>
>