[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] handledEvents wildcards clarification
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]