wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Wildcard notation in event names
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Tue, 31 May 2005 17:42:26 -0400
This is one of those nasty conundrums
... the description of the EventDescription type is the most sensible place
to talk about naming events while the natural place to talk about the wildcard
issues is PortletDescription. A reasonable split in the discussion with
a forward reference is what we have done at other such places in the spec.
On the lines of a conformance statement
concerning Consumers respecting the wildcard definition, I don't think
we have one ... how about changing
"Each
name specified is allowed to end with a “*” character to indicate the
Portlet could publish any event whose name starts with the characters before
the “*” character"
in 5.1.15 (publishedEvents ... handledEvents
would then want to reference this conformance statement) to
"Consumers
doing event distribution are REQUIRED to match event names ending with
a “*” character to any event whose name starts with the characters before
the “*” character"?
Rich
Subbu Allamaraju <subbu@bea.com>
05/31/05 05:26 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] Wildcard notation
in event names |
|
Thanks. The reference to 5.1.15 provides the context
I was looking for.
I suggest that this paragraph be moved to 5.1.15 since while reading
5.1.11, it won't be clear to the reader what this discussion is about.
My other question is, is the Consumer required to honor the wildcard
notation? I think the anser is YES, but I would like to have this
confirmed in the spec.
Regards,
Subbu
Rich Thompson wrote:
>
> We had a discussion about this ... basically the match algorithm is
that
> the event name must start with the string before the '*' character.
The
> '/' is in used as the example for making hierarchical names as this
> matches the syntax for WSN Topics and makes supporting both (should
a
> Producer choose to do so) easier.
>
> I have updated the section reference to 5.1.15 in draft 10 ... wish
I
> knew why Word is willing to keep only some of these references in
sync.
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 05/27/05 04:57 PM
>
>
> To
> wsrp
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
> [wsrp]
Wildcard notation in event names
>
>
>
>
>
>
>
>
> In Section 5.1.11, we have some text about using wildcard notation.
Here
> is the text:
>
> "Since an event’s name can be refered to in a wildcard fashion
(see
> section 2.1.2), Portlet developers are encouraged to organize their
> event names hierarchically. An example of such an organization would
be
> events carrying changed address information on an application being
> organized as “applicant/address/streetChanged”,
> “applicant/address/cityChanged”, etc.. Such an organization would
allow
> another Portlet’s metadata to simply say that it is interested in
all
> events starting with “applicant/address/”. The use of the “/”
character
> to denote levels within such a hierarchy is suggested as a means to
> enable easier reading of these hierarchical event names, but should
not
> be taken to imply that the event names are treated as XPaths since
they
> are not XPaths."
>
> [Note that Section 2.1.2 does not exist in Draft 9.]
>
> This text does not clearly say that using "/" is THE spec-defined
way of
> organizing events into hierarchical groups. The use of "/"
is introduced
> directly in an example, and not in the preceding text on event
names.
> IMO, the intent is not well-captured, and could be interpreted differently.
>
> Secondly, it is not clear if a Consumer can choose not to support
> hierarchical naming of events. If a portlet says that it would like
to
> receive "/foo" events, and if another portlet fires a "/foo/bar"
event,
> can the Consumer do an exact match on event names and not dispatch
the
> event? Or, SHOULD/MUST the consumer try to match?
>
> Comments?
>
> Regards,
> Subbu
>
> ---------------------------------------------------------------------
> 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]