/sports/*
then there is no way for the subscriber to know what subtopics of sports exist, so he basically has no choice but to subscribe for "/sports/*" even if he only cares about tennis.
I think either the TopicSpace(s) need to be exposed as RPs or operations (e.g. URI[] getRooTopicSpaces(), getChildTopics( nsURI )) need to be added to the NotifProducer portType.
I agree this is another good one to discuss w/ William.
Stefan Lischke wrote:
Yeah nice Idea, i also like 3) and it wont be a problem to write 2 little XSL's that transform from and to TopicSpace XML shema. We just store our format and if someone wants to get the TopicSpace in "old fashion", we transform it back.
One problem that i also see is the ResourceProperty of NotificationProducer:
its just a set of topics, no TopicSpace.
IMHO it would be better to make the TopicSpace (in any shema, maybe ours or the one defined by WS-Topics) a resourceProperty.
--
<!-- ======== Resource Properties for NotificationProducer ======== -->
<xsd:element name="NotificationProducerRP" >
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="wsnt:Topic" minOccurs="1" maxOccurs="unbounded" />
<xsd:element ref="wsnt:FixedTopicSet" minOccurs="1" maxOccurs="1" />
<xsd:element ref="wsnt:TopicExpressionDialects"
minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
---
Ian Springer wrote:
[.......]
1) (XSLT?) transform the TopicSpace doc(s) to the form:
<sportsnews:sports xmlns:sportnews="http://sportsnews.com/";> <tennis /> <basketball /> </sportsnews:sports>
or
2) transform the topicepression xpaths to a form that can be applied to the TopicSpace doc(s), e.g. "/[EMAIL PROTECTED]"http://sportsnews.com/"]/[EMAIL PROTECTED]'sports']/[EMAIL PROTECTED]'tennis']"
3) Do not use the TopicSpace/Topic types at all and instead just store the TopicSpace doc(s) from the get-go in the form:
<sportsnews:sports xmlns:sportnews="http://sportsnews.com/";> <tennis /> <basketball /> </sportsnews:sports>
I think 1) is preferable over 2), because it could be done once up front (as well as if/when topics are added or removed at runtime), whereas 2) would have to be done for every call to subscribe() or notify(). I think I like 3) better than 2).. I just don't see the point of the TopicSpace/Topic types - XPaths can't be applied to them directly and neither the consumer not the publisher accesses them directly. I might very well be missing something; this is one of the things I want to discuss with William this afternoon.
Ian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
