Re: [wsrp] handledEvents wildcards clarification

[Rich Thompson <richt2@us.ibm.com>]

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