[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes from Friday 5/20 WSN TC F2F
Friday Morning F2F Minutes: Your humble Scribe: Steve Graham William reviews the Agenda for the morning. Peter reviews the revised process document (it will be posted on the TC Web site) - updated the document to reflect recent terminology changes made by OASIS TAB - we are now working on cd-02 level of the documents - editors should refer to the table in the process document to make sure they are consistent with the file names, URIs, document identifiers etc. - need to agree on the words in the status section (peter to fix the current draft before posting to replace the status text with more modern text and to replace WSRF with WSN) Motion to approve the the document, subject to modification Peter agrees to make. Motion approved. Martin's proposed issue for BaseN (putting the Notify information in headers): - Basically a "raw" with notification headers as SOAP headers - no notify wrapper in the body, but should be allowed to put the "notification" messages as headers - sgg raised concern about "defining" headers or bindings in the spec - Proposal is to "formalize" the meta data as stand alone, and allow the material to appear wherever folks wanted - if these elements are associated with a Notification Message, then they must convey the information specified in BaseN - define the "meta data" wrapper (subscriptionReference, topic etc.)components before notify, update notify description to reference these descriptions - update the "raw" to make a non-normative statement that these elements may appear in raw messages, for example as soap-headers - David has 3 comments - likes it, good to put functionality outside the current state - in policy it might make sense for an NP to describe that it puts these elements in raw messages - do we need to reopen the Notify decision? No new use case was brought up to suggest changing the TC's decision - William notes that we cannot make normative statements that the elements MUST convey the semantic if they appear anywhere in the message. These elements provide information about A notification, but, if one notification is wrapped within another (ie forwarding a notficiation within another notification) then clearly these elements may not apply to the outer element. - Any objection to accepting this proposal from Martin? - This proposal was agreed. Peter has a comment that may affect Base. Normative power of files vs text. We didn't agree on the normative precedence power. TC agrees to text that appears in BaseN (was copied from WSRF). AI: BrokeredN and Topics editors to use the same text as is found in the BaseN draft emailed to the list by David Hull on 05/19/05. (modify the Topic version of the text to remove reference to WSDL files (WS-Topics doesn't have WSDL)). William: would people consider the decision on Pull Notification, some slight modifications. When the buffer is full, the goal is to discard the oldest message first. Difficult to determine age, therefore we agreed to keep silent on this. These could be policies on PullPoint. TC agreed not to take further action on William's proposed amendment. Discussion on Issue 4.2 related to Topics: - Peter and Sid caucused on this issue. - Topic Set document concept needs better normative specification. Need normative description on mapping from TopicSpace document to TopicSet document. - Describe Topic Set before Topic Space. Perhaps consider a paragraph to "position the concepts" and then describe topic space and then topic set. - we don't describe an XSLT to go from a topic space forest to a topic set. Proposal was to leave the document silent on this matter. - Rename TopicSpace to TopicMetadata, there are some people confused by the name TopicSpace, there are some products that use TopicSpace to mean other things. Perhaps change TopicSpace to TopicNameSpace. - New RP on NP to retrieve a TopicSet document, this is in addition to to the current RP allows the topic information to be returned as topic expressions - Allow additional metadata to be embedded in the TopicSet document - Topic Set should allow additional metadata to be embedded in it. It needs to be a clearly defined area where the additional metadata should appear. Now the TC attempted to Modify the proposal as follows: Issue: The Topic Set document is not completely specified, and there is no normative specification for transforming topic entries from a topic space document into the Topic Set document Proposal: 1. Additional text to emphasise the role of the Topic Set -Add precis -Add example 2. Normatively specify the structure of a Topic Set document and the interpretation of the XPATH-like Expressions, not the process that the NP uses to build it (so no need to include XSLT) 3. Rename TopicSpace to TopicNamespace 4. New minOccurs=0/maxOccurs=1 ResourceProperty on NP to retrieve the TopicSet as a document in addition to the existing Topics RP. 5. Allow additional metadata to be embedded in the Topic Set document -NP can elect to insert this metadata if it chooses -Full XPATH dialect would allow selection against this metadata. If a topicExpression evaluates to include the wstop:TopicMetadata nodes, these nodes are not included in the representation of topics represented by the expression. ie if the expression is //true(), then no nodes are selected, no topics are represented by the expression. If a wstop:TopicMetadata node is part of the selected node result, it is not included in the set of topics represented by the expression. Peter went item by item in the proposal asking for objections. TC approved the amended proposal. <<resumed after break>> David's new issues with regards to weakening MUST in a couple of places. Version F of the document. Line 522 element MUST accept all NotificationMessages ... delete the sentence. No objections. AI BaseN editor to execute this agreement. Beginning of Section 5.2 Pause Subscription reword to remove the MUST. No objections. AI BaseN editor to execute this agreement. Beginning of Section 4.2, will result in the creation of ... change to MUST result in the creation of ... No objections. AI BaseN editor to execute this agreement. discussion on the addtional paragraph "The NP MUST respond with ..." in the description of wsnt:Filter/wsnt:TopicExpression/@Dialect. This entire description of the component needs to be more clear. AI BaseN: editors Bryan to clarify. Broker issue, WSN3.4, issue related to demand-based publisher - issue, the name and issue the boolean flag in how it is requested in the publisherRegistration request - is this a case of policy like use raw, use notify was in Subscribe Request? - Martin argues it should be an explicit flag, not policy. - Make sure it is clear what are the required constraints on the PublisherEPR depending on the value of the demand flag. - Change the name of "composable" to "broker initiated" Proposal: close this with action agreed to "Composable" to "broker initiated" and to clarify the required constraints on the PublisherEPR depending on the value of the demand flag. Agreed. Observation: we have approach agreed for all issues on all specifications.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]