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

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

Interestingly, on point 4, I notice the markup
uses the ?, *, + notation! This is accidental
in that I used the same notation from an early
spec from the XML family and here I guess
the use of DTDs was still prevalent. At least
that's my excuse :-)

Too late to make that many changes but my own
preference would have been to use the (x..y)
notation to allow (1..2), etc.

Best regards

Steve
---
Stephen D Green




2010/1/20 Stephen Green <stephen.green@documentengineeringservices.com>:
> Kevin, TAG TC,
>
> My dispositions inline below...
>
> Apologies so few agreements here from me
> to make changes - but each change might need
> subsequent review again and I think we agree
> to try to keep to ones which will lead to changes
> we would have no trouble all accepting - at this
> stage.
>
> 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.
>
> I think we define 'Target' well enough and I agree conformance target
> is not defined in so far it differs subtly from just plain 'target'
> (if it does).
> I'm not sure it differs conceptually from 'target' enough though to warrant a
> definition. I'm open - it's worth adding to the list of issues. I just think we
> all spent a good while choosing our list of terms and didn't pick up on it
> so I'm wary of adding it at this stage in view of the time it might take to
> agree a clear and precise enough definition. Easier, if we agreed later,
> to drop the word 'conformance' from 'conformance target'.
>
>>
>> 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"?
>
> I don't think we have enough knowledge to specify this as
> part of the model. There could be many ways to use implicit
> values, such as the sequence of TAs in a TA set (where each
> TA target gets it's value from a combination of a target scheme
> specified somewhere and the TA Id or the position of the TA
> in the set sequence). I don't think we should be specifying that.
>
>>
>> 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"
>
> Mmm. Not sure this would be helpful. I don't see harm in
> duplicating the note about terminology to have it where the
> reader needs it. It seems they might have skipped the terms
> section or have the convention quoted out of context so I
> see no harm allowing a little duplication. The terms are not
> really normative language as such (even though part of a
> normative section) and I take it they are there as explanation.
> I'm wary of failing to add something normatively to the body
> of the spec just because we think we have covered it in the
> preamble. It is, I think, an important normative statement that
> the model does not have to be understood or implemented
> with an object oriented paradigm in mind (mainly because
> XML markup itself is not truly object oriented as such but is
> just conveniently descibed in many cases like ours loosely
> using OO terms). Also I wouldn't say the terms are overloaded.
> I wouldn't be surprised to find they predate OO and it might
> be OO which overloads them :-) I think the terms 'class', etc
> go back to the Ancient Greeks and Plato and Aristotle and
> have been variously overloaded and borrowed by IT-ers ever
> since.
>
> It's that we know that many readers will come from an OO
> background and be inclined to interpret the terms more
> strictly in an OO sense than we intend. We don't want their
> own overloading to influence their interpretation of the
> normative statements.
>
>>
>> 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?
>
> Both conventions are used with UML, XML, etc. I don't think
> I can agree to rejecting the convention (x..y) in favour of the
> Kleene/Regex notation. There is a reason for using (x..y) which
> is that since XML Schema took over from DTDs, there has been
> the possibility of constraining cardinality to e.g. (1..6) whereas
> as far as I know DTDs and regex/Kleene character notations
> are limited to expressing (1..*), (1..1), (0..1), (0..1) and (0..*).
>
> It just means if we ever wanted to limit an attribute or association
> in the model (as in the markup) to (0..2), say, we could do so
> without having to change our notation. (Plus changing it could
> mean introducing errors at this stage which might never get caught.)
>
>>
>> 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.
>
>
> After some thought and the discussion in the meeting I think
> we can make the 'content' (1..1) for each element (and attribute)
> where it is specified.
>
> That is to say, each element has with the model specifying
> "content  : string" would be represented in the markup as
> having "base='string'" (or "base='normalizedString'") and it is my
> interpretation of the (1..1) that it means the string exists in the
> markup but it does not mean we have to have a way to enforce
> the content of the string in an instance to be non-blank. That
> would be an unreasonable requirement on tools. So in an
> instance, typically, "<normativeSource/>" would still be valid;
> the fact the schema has "base='normalizedString'" means it is
> a representation conforming to the markup. I don't think we
> need to try to specify this as it would create more problems than
> it solves to specify it more than having the models for the
> classes simply say "content : string (1..1)".
>
>>
>> 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).
>
> Agreed, as per last meeting.
>
>
>>
>> =========================================================
>>
>> 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
>>>
>>>
>>
>>
>