OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Preparation for WSN face to face: WS-Topics



Hi all,

We agreed during the last conf call to focus on WS-Topics and
WS-BaseNotif during our upcoming face to face, rather than
WS-BaseNotification which has been getting the most attention so far. In
order to organize the WS-Topics part of the discussion, I listed the
issues in the order I propose to address them. Rather than assigning
specific times to each one, let's agree on the order, allocate a max
amount of time (I suggest 30 minutes) to each and drive through them
during the time we decide to allocate to WS-Topics.

So here it is:

*****These three issues have the potential to result in very large
changes to the spec, so we should start with them otherwise we risk
wasting our time working on smaller issues that become irrelevant if we
make a major change:

- Issue 4.12: General purpose mechanism for structuring topics

- Issue 4.13: Reuse same construct for Topic and TopicSpace

- Issue 4.14: Multiple schemes for filtering

*****Once we have disposed of the previous three, we can attack the
remaining issues in this proposed order:

- Issue 4.1: Best practice document for topics
[Suggestion: handle 4.6 (Events for notifying changes to topic set) if
the TC agrees that this should be resolved without normative changes to
the spec]

- Issue 4.2: source document for FullTopicPathExpressions (the topic set
is different from a topic space and not fully specified)

- Issue 4.4: domain-specific extension to topic spaces (how can you
extend if you don't have access to the domain name used by the initial
topic space).
[Suggestion: handle issue 4.5 (complexity of the AliasRef mechanism) and
issue 4.17 (how to reach children of alias Topic?) at the same time
since AliasRef is related to the ability to fulfill the use case in 4.4]

- Issue 4.7: The Topics resource property of Notification Producer is
expressed in terms of TopicExpressions which can only be evaluated once
you've found the "right" instance of the topic space.

- Issue 4.15: Wildcards in Topic Set
[Suggestion: handle issue 4.16 at the same time]

- 4.19: XPath capabilities for FullTopicPath Expression 

- Issue 4.3: XPath 1.0 as an additional dialect for
FullTopicPathExpression 

*****Finally, these issues should be smaller and faster to resolve (as I
type this I am shivering in the realization that these are foolish word
to say in a standard group), so I list them separately here, the idea
being that we go pick from this list when we have a little bit of time
before a break:

- Issue 4.10: Inconsistent topic path dialect URI naming

- Issue 4.9: Specifying the Ad-hoc topic space is cumbersome

- Issue 4.11: Semantics of Topics Hierarchy

- Issue 4.20: SimpleTopicExpression type as xsd:token 

- Issue 4.18: Is a complete tree closed?
(I don't understand this issue, so I put it in this category so that we
can start by spending a bit of time at least clarifying it)


Comments?

Thanks,

William


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]