[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsn] Draft version h
David
On the June 6th teleconference, we discussed a couple of the issues that
you raise in this posting
1. Your concern on 2.1 (Topics option), where you said "I don't believe we
have quite made a clean break here. For example, FixedTopicSet is still
REQUIRED (by its cardinality) regardless of whether topics are supported.
Also, GetCurrentMessage requires topics. I'd like to open an omnibus issue
for this (and other points I've already sent to the list) and at least
clarify whether the current status is acceptable."
It does appear that 2.52 has not yet been fully implemented (the bit still
to be done is to set minOccurs=0 on TopicExpressionDialect). My
interpretation of the current status (draft 1j + full implementation of
2.52) is as follows:
A NotificationProducer is not required to support any Topic filter
expressions. It is also not required to support any WSRF-RP properties. If
it does support WSRF-RP properties, then it is not required to support any
Topics or TopicExpressionDialects. It does have to return a FixedTopicSet
property - this should be set to TRUE (having no Topics and
FixedTopicSet=false implies that at some future time it might support some
Topics). A NotificationProducer is not required to support
GetCurrentMessage, but there is no point in doing so if it doesn't support
Topics since GetCurrentMessage retrieves by Topic.
This would appear to meet our primary goal - allowing simple
NotificationProducers to have no knowledge of topics, however as you point
out support for Topics is not completely orthogonal to everything in BaseN.
Nobody who is on the call seemed to be concerned about this, however we
felt we could not close a discussion without you being present. If you feel
you wish to pursue this further, I suggest you bring it up on Monday's
call.
2. Your concern on useRaw where you say "The useRaw element should only
occur once. I've added a MUST to that effect, but ideally this should be
in the schema. Currently, we put useRaw inside {useRaw|any}*, which says
it can occur any number of times. Either it should be before everything
else, with cardinality 0 .. 1, or we should find another way to impose the
constraint in the schema.".
I think the consensus on the call was that documenting this in the
specification was adequate for now - I don't think that it is very likely
that someone would inadvertently put two useRaws in, relying on schema
validation to check it. Leaving the schema declaration as any* allows us
the option of moving to a more advanced policy grammar in the future.
Regards
Peter Niblett
David Hull
<dmh@tibco.com>
To
27/05/2005 22:17 wsn@lists.oasis-open.org
cc
Subject
[wsn] Draft version h
Attached please find draft "h" of BaseN. I started by accepting all
changes in draft "g", on the assumption that we could recover that
information from draft g itself. Please double-check everything here for
typos.
I have fully executed on these issues in this revision:
2.33
2.48
2.51
2.52
These appeared already to have been done, whether by myself or others. All
of them will need to be verified:
2.6
2.36
2.39
2.43
2.50
2.53
2.54
I have partially executed on these (see notes below):
2.1
2.23
2.24
2.34
2.46
2.49
These remain to done, though some of them have been started
2.25 (need to define and describe Destroy message)
2.32 (schema changes needed)
2.45 (may already be done -- I didn't check)
2.46 (may need schema changes -- see below)
2.47
I've also made a few editorial changes. I've explained the reasons behind
them in comments.
In trying to execute on some of the partially executed issues, I've run
across a few potential issues:
2.1 (Topics option) I don't believe we have quite made a clean break
here. For example, FixedTopicSet is still REQUIRED (by its
cardinality) regardless of whether topics are supported. Also,
GetCurrentMessage requires topics. I'd like to open an omnibus issue
for this (and other points I've already sent to the list) and at
least clarify whether the current status is acceptable.
Issues 2.24 and 2.25 interact. If an NP or SM is not a Resource,
what does the boilerplate about WS-RAP mean? I've removed that
boilerplate for the nonce (more by accident than proactively). There
should probably be a general statement in section 2 to the effect
that WS-RAP applies where WS-R behavior is supported, or whatever we
really want to say.
The useRaw element should only occur once. I've added a MUST to that
effect, but ideally this should be in the schema. Currently, we put
useRaw inside {useRaw|any}*, which says it can occur any number of
times. Either it should be before everything else, with cardinality
0 .. 1, or we should find another way to impose the constraint in the
schema.
2.47 Do we want to include attribute extensibility everywhere?
Is 2.34 subsumed by 2.49, or am I missing some distinction?
Around line 540, we say that the NP MAY refuse to process
subscriptions and later it MAY return a fault. What is the behavior
if it doesn't?
Section 6 needs to be boiled down a bit.
[attachment "wsn-WS-BaseNotification-1.3-draft-01h.doc" deleted by Peter
Niblett/UK/IBM]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]