Re: [wsrp] handledEvents wildcards clarification

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

ok, I'm not too hung up on this, but maybe we can make a clarification 
so that people are aware that the "." is overloaded for hierarchie and 
wildcards.

Stefan

Stefan Hepper wrote:
> 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
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
>