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

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