sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Revised proposal to resolve issues 57, 58, and 59
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: Eric Johnson <eric@tibco.com>
- Date: Mon, 2 Feb 2009 13:41:20 +0000
Eric,
I'm quite happy with jndiUrl being done
that way. My concern was about referring to the naming convention
for intents. Can't attribute and element values work the same way
as attribute and element names? I mean following the extra rule,
of course, so jndiUrl could be an element name or attribute value. Using
the intent convention, wouldn't jndiUrl as an attribute value have to be
JNDIURL?
nonpersistent - fine, JMS headers, also
fine, just need to make an editorial update to the attribute definitions
to clarify the relationship with JMS headers.
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
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
Eric Johnson <eric@tibco.com>
30/01/2009 02:41
|
To
| Simon Holdsworth/UK/IBM@IBMGB
|
cc
| sca-bindings@lists.oasis-open.org
|
Subject
| Re: [sca-bindings] Revised proposal
to resolve issues 57, 58, and 59 |
|
Hi Simon,
Thanks for responding. My thoughts in return follow:
Simon Holdsworth wrote:
Eric,
Thanks for providing the extra detail for the specific names.
The approach for intent names is a bit confusing, in that if the intent
name is an acronym its in capital letters - I assume that means only if
the intent name is entirely an acronym, rather than including an acronym,
possibly at the start of the name. Because of that I'd rather not
define attribute and element values in terms of the intent definition -
can't we just say that they follow the same convention as the names of
attributes and elements (i.e. initial letter lower cased)?
Since the only convention from the assembly spec that
deals with acronyms in values expects them to be capitalized, I was just
piling on to that pattern. The notion of just the initial letter
lower cased falls over for the @jndiURL attribute. Would you have
it be "jNDIURL", or "uRL"? In code I write in
Java, this is something that I would tend to write as "jndiUrl",
rather than "jndiURL", simply because my brain has turned both
"JNDI" and "URL" into words, and then it follows naturally
into the standard camel case pattern. So that's how I wrote it up.
@jndiURL is the real hang up. We can decide what we want it to look
like, and then come up with a rule for it, then I think we can move forward.
I thought about it, and picked the rule that I like. The choice is
fairly arbitrary, though.
Also not sure whether nonpersistent ought to be nonPersistent ...?
I went to the dictionary on that one. Websters online
seems to think it is one word: http://www.merriam-webster.com/dictionary/nonpersistent.
For "JMSType", "JMSDeliveryMode",
"JMSTimeToLive", "JMSPriority", and "JMSSelector"
the reason for including the JMS prefix was that these refer to standard
attributes of a JMS message, rather than being there just because they
are part of the JMS binding spec. However I don't feel that strongly
about this so long as the description of the attributes is clear about
the relationship.
I did understand that these attribute names are simply
mimicking the JMS specification. I couldn't think up any consistent
rule that allowed both "@uri" (assembly), "@jndiUrl"
(binding.jms), and also allowed "@JMSType". I wasn't excited
about changing them, but nor did I think alignment with the JMS specification
was any more or less compelling then aligning to our naming conventions.
-Eric.
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
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
Discussion:
As I go through this attempt at establishing a naming convention, I'm still
suspicious that our approach to acronyms is flawed. I tend to agree
with sentiment expressed in our call - I think by Simon H. - that acronyms
should be treated as if they were words. Which means we get @uri,
or @jndiUrl, and a "jms" and "soap" intent. For
example, I note the Assembly Binding complex type, which has an @uri element.
The naming conventions expressed in the Assembly specification do
not speak to how this one should be treated, since the "CamelCase"
convention usually applies to words, and of course, "URI" is
not a word. Following naming convention I proposed in an earlier
email, this attribute would instead be @URI. So here's a few examples
of the problem (current state listed first, options following):
(Assembly) @uri vs. @URI
(binding.jca) @jndiURL vs. @jndiUrl or @JNDIURL
(binding.jms) @JMSType vs. @jmsType
(binding.jms) @JMSDeliveryMode vs. @jmsDeliveryMode
(policy - value) SOAP vs. soap
(policy - value) JMS vs. jms
To fit with the current state of both the assembly and policy specification,
I think we have to treat element and attribute names with acronyms as if
the acronyms were words. However, policy intents need to treat acronyms
as all caps items. An annoying inconsistency, to be sure, but that's
how I proceeded below. The alternative would be to have Assembly
state a position with regards to acronyms in element and attribute names,
and policy change its position with regards to the intents "JMS",
and "SOAP".
Proposed resolution for issues 57, 58, 59:
Each specification (ws, jms, jca) adds a section 1.4 - Naming Conventions.
The text of that section as follows (between the two line breaks):
This specification follows some naming conventions for artifacts defined
by the specification. In addition to the conventions defined by section
1.3 of the Assembly [SCA-Assembly] specification, this specification adds
two additional conventions:
- Where the names of elements and attributes consist partially
or wholly of acronyms, those acronyms will be treated as if they are words,
and use the CamelCase conventions outlined in the Assembly specification.
For example, an attribute might be named "uri", or "jndiUrl".
- For the values of XML Schema elements or attributes defined
in this specification, the values follow the same convention as the names
of intents in the Assembly specification. If the value is of type
QName, the local part of the QName value follows the same convention as
names of intents.
For resolution of http://www.osoa.org/jira/browse/BINDINGS-58,
also apply the following changes to the binding.jca specification:
(In document sca-binding-jca-1.1-spec-cd01-rev4.pdf)
Rename element "jca.outbound.connection" to "outboundConnection",
all occurrences.
Rename element "jca.inbound.connection" to "inboundConnection",
all occurrences.
Rename element "jca.outbound.interaction" to "outboundInteraction",
all occurrences.
Rename element "jca.inbound.interaction" to inboundInteraction",
all occurrences.
Rename attribute "binding.jca/@jndiURL" to "jndiUrl",
all occurrences.
The value "ifnotexist" (multiple attributes) should everywhere
be changed to "ifNotExist".
The values of the "resAuth" element, "Container" and
"Application" should be renamed to "container" and
"application".
For resolution of http://www.osoa.org/jira/browse/BINDINGS-59,
also apply the following changes to the binding.jms specification:
(In document sca-binding-jms-1.1-spec-cd01-rev4.pdf)
Rename attribute "binding.jms/jndiURL" to "jndiUrl"
for all occurrences
The value "ifnotexist" should everywhere be changed to "ifNotExist".
The attributes "JMSType", "JMSDeliveryMode", "JMSTimeToLive",
"JMSPriority", and "JMSSelector" are renamed to "type",
"deliveryMode", "timeToLive", "priority",
and "selector", respectively.
Change "PERSISTENT" value to "persistent"
Change "NON_PERSISTENT" value to "nonpersistent"
Change "sca:MessageId" value to "sca:messageId"
Change "sca:CorrelationID" value to "sca:correlationId"
Rename jndiURL attribute to "jndiUrl"
Rename the element "wireformat.jmsdefault" to "wireFormat.jmsDefault"
The "jms" intent referenced in section 5 of this specification
needs to be capitalized as "JMS" to correspond to the Policy
specification.
For resolution of http://www.osoa.org/jira/browse/BINDINGS-57,
also apply the following changes to the binding.ws specification:
Rename the intents (section #4) from "soap", "soap.1_1"
and "soap.1_2" to "SOAP", "SOAP.1_1", and
"SOAP.1_2", respectively.
Hopefully, this wraps it up.
-Eric.
--------------------------------------------------------------------- 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
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]