I think the Topics resource property is a TopicSet and could be flattened to an Xml document if we use XmlBeans...
The problem with using the TopicSpace is that there is a restriction that the topics only be of that namespace, where the set contains ALL topics -----Original Message----- From: Stefan Lischke [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 1:05 PM To: [EMAIL PROTECTED] Subject: Re: Topics Filtering Hi, 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]'spo rts']/[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] > > -- My place : http://user.cs.tu-berlin.de/~lischke --------------------------------------------------------------------- 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]
