Hi Simon,
It would appear that the "wireFormat" description still points to the
wrong place, even in the PDF.
Otherwise, everything else looks fine. Thanks for the PDF form.
-Eric.
On 02/11/2010 02:36 AM, Simon Holdsworth wrote:
OF67985F26.FFE22DDB-ON802576C7.00385D73-802576C7.0039E34F@uk.ibm.com"
type="cite">
Eric,
I have no idea how there are two
references
in the @selector definition - I only see two in the final or final
showing
markup views, and if I accept all changes I only see one reference.
However
I've retyped that part which should have fixed the duplicate cross
reference.
I don't understand the comments
about
section 3.2 and 3.3 - the text has the options listed including
numbers,
with 1) also having (highest priority) and the last having (lowest
priority).
There is no text after the normative statements, the priority order
is defined within the normative statements.
Here's a .PDF version with the
selector
and wireformat references fixed:
I'd suggest we use this as the basis
of the resolution rather than the .doc one so there's no ambiguity,
although
its not so easy to move from one change to the next.
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC
Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com
Hi Simon,
Thanks for putting this together.
Items (I'm using OpenOffice so I could be seeing bugs in conversion):
- Section 3: definition of
/binding.jms/messageSelection/@selector
- seems to have a reference to both section 3.2 & 3.3
- in the ../headers/property elements, I like the
addition
of "and type" that appears to be new with this proposal.
- Section 3: definition of
/binding.jms/response/wireFormat
- the link that used to go to section #4 now seems to go to section 3.2
- New section 3.2 doesn't actually seem to have
the priority
orders specified after either of the normative statements in the text,
but does have them at the end of the document with all the normative
statements.
- Section 3.3 suffers the same problem as 3.2
- I'm seeing a change to BJM40010, which looks
fine, but
isn't a part of this resolution. Looks like this is the broken
reference
you indicated is fixed. The text of the normative statement is
doubled-up,
for me.
The problems all might be artifacts of the
DOC --> ODT conversion, but I suspect not. Can you send a PDF?
-Eric.
On 02/08/2010 07:00 AM, Simon Holdsworth wrote:
Folks,
As per our discussion on Thursday, here's an updated copy of the latest
revision of the JMS binding spec with the proposed updates to resolve
BINDINGS-95,
105 and 106.
All marked updates pertain to the resolution of these issues; there was
also a broken reference in cd03-rev1 which I've fixed here as an
aide-memoir.
I've made some additional editorial changes at the places where the
original
normative statements were removed, to point to the rules defined in the
new sections. I've also clarified that the user property elements
provide
the name and type of the user properties, and included "selector"
as one of the URL paramaters with specific semantics.
Regards, Simon
Simon Holdsworth
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
---------------------------------------------------------------------
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
|