Re: [wsrp] handledEvents wildcards clarification

[Stefan Hepper <sthepper@hursley.ibm.com>]

Hmm, than it doesn't really make sense to me that we recommend also 
using the "." to denote specific parts of a hierarchie.
I don't like the "foo.." notation, this looks confusing to me.

Stefan


Rich Thompson wrote:
> 
> We had insufficient people to make last week's call productive, so it 
> was canceled.
> 
> My recollection of the discussion when this was proposed falls exactly 
> along the lines of Kevin's comments, namely that the trailing '.' is the 
> wildcard character and therefore not included in the string to match 
> (i.e. "foo." means match anything starting with "foo" and does not 
> require that "foo" be followed immediately with a '.'). For those 
> wanting to match a hierarchical level, this means specifying something 
> like "foo..", but this is the common practice for where '.' is used as 
> the wildcard character.
> 
> Rich
> 
> 
> From: 	Stefan Hepper <sthepper@hursley.ibm.com>
> To: 	WSRP TC <wsrp@lists.oasis-open.org>
> Date: 	11/12/2007 03:32 AM
> Subject: 	Re: [wsrp] handledEvents wildcards clarification
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Any updates on this one (sorry I missed last weeks call)?
> 
> I think we need to have a clarification here that the "." is included in
> the pattern matching (or at least that is what I remember we wanted to
> achieve).
> 
> Stefan
> 
> Kevin Frender wrote:
>  > Wildcard-matching of event names is described in section 4.1.16 of the
>  > specification with the sentence:
>  >
>  > Each [event] name specified is allowed to end with a "." character to
>  > indicate the Portlet is willing to process any event whose name starts
>  > with the characters before the "." character.
>  >
>  > My strict, literal interpretation of this sentence is that the "."
>  > character on the end of the handledEvent string is NOT included as part
>  > of the pattern to be matched-- the pattern to be matched includes only
>  > "characters before the '.' character" and NOT the '.' itself.
>  >
>  > I don't think this is what was intended by the technical committee-
>  > section 4.1.11 talks about using "." to delimit hierarchy levels in
>  > event names and implies the reason why "." is used is for wildcard
>  > matching.
>  >
>  > I'm pointing this out to try and ensure consistent interpretation of the
>  > specification.  I think the specification either needs a clarification
>  > that the "." is included in matching the wildcard name with an event
>  > name (such as "... Portlet is willing to process any event whose name
>  > starts with the characters before and including the '.' character"), or
>  > we need to agree that the '.' is NOT included and leave the
>  > specification worded as it is now.
>  >
>  > One potential reason to leave the specification worded as it is now is
>  > that it allows for more powerful wildcard matching.  For example, WSRP
>  > defines standard names for mode and state change events:
>  >
>  > {urn:oasis:names:tc:wsrp:v2:types}newMode
>  > {urn:oasis:names:tc:wsrp:v2:types}newWindowState
>  >
>  > These event names do not use '.' to separate hierarchy levels as section
>  > 4.1.11 suggests, so if a portlet wanted to subscribe to both of these
>  > events there is no way to do it with a wildcard if the '.' is included
>  > in the wildcard-matching pattern.  However, if the '.' is not included,
>  > a handledEvents specification of
>  > "{urn:oasis:names:tc:wsrp:v2:types}new." would match both events.
>  >
>  > If we do leave the specification worded as it is now, it is still
>  > possible to ensure a '.' is matched for a wildcard- simply specify two
>  > periods on the end of the wildcarded event name, such as
>  > "somens:localPart.."
>  >
>  > JSR286 has this same issue and obviously we would want the
>  > specifications to match in their interpretation.
>  >
>  >  Kevin
>  >
>  > Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
>  affiliated entities,  that may be confidential,  proprietary, 
>  copyrighted  and/or legally privileged, and is intended solely for the 
> use of the individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in error, please 
> immediately return this by email and then delete it.
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  You may a link to this group and 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.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
>