BINPIDF, Filtering ================== ------------------------ - winfo-filtering requirements * No discussion, no open kissues * WG item, need reviewers for it - Jonathan Rosenberg: draft seems to replicate a lot of generic filtering requirements. HK: the filtering reqs shouldn't even exist any more - JR: The model was that there doesn't seem to be a lot in common between filter and winfo reqs. At the very least, have a generic doc and specific docs, or put them into one doc. KD: we've gone around and around on the subject. No need to make more document work. It's a process issue and up to chairs. - Robert Sparks: who wants to volunteer reviewing these drafts? No one is leaping to the mike. Robert will assign people. - JR: What is the motivation for a requirement calling for getting notifications when a subscription is expiring? Why? No pressing need, take it out. - JR: Requirements are pointless if we go with XPath. Because you can ask for anything. ------------------------- - filter-reqs * Requirement to ask for presence doc structure. Useful? - Aki to send a note to the list about the requirement saying scrap the requirement. - RS: Main issue seems to be to get attention to the draft. - JR: Target URI requirement: there's a much bigger probem here. Issue: subscriptions can be to lots of different types of users. Applicability of a filter is complicated issue. Mapping only user=x applicability is not enough. What exacly is the requirement in how to map a filter to a set of resources. -> Need to review the concept, no new requirements - Jon Peterson: There certainly seems to be things we should take on. - Brian Stucker: May not know what to filter because of the RPIDS stuff. - JR: Extensibility. Shoudn't have to extend filter language to address extensions to PIDF. --------------------- - filtering mechanism (filter format) - JR: Really big issue: XPath, or something else (syntactic vs. semantic filter) Syntactic is very broad in applicability. Semantic requires understanding of PIDF structure. Authorization is very difficult. With hierarchical structure, this becomes much more difficult. - Keith Drage: Don't you update filters as presence information changes? JR: Typical use case is interested in some specific subset, and needs specific information. - Lots of discussion about the relationship of presence filtering and authorization. JR is going to submit a concrete proposal, but the conclusion was leaning towards a unified semantic solution. - Some more discussion about the syntactic and semantic approaches. Syntactic requires deeper knowledge of the structure, extensions etc. - Paul Kyzivat: In the end, to do something intelligent, you need to know the syntax in the context of the information. - BS: Who is going to do this filtering? The composer? - JP: Going back to classes (facets) in publishing. Subcribing to a facet would enable some of this, but problem is that "classes" are arbitrary. We got rid of Class header. - BS: Is filtering a composing function, or a stripping function? With semantic approach it necessarily needs to be a semantic approach. - Aki Niemi: Semantic approach means standardizing profiles, which may not be specific enough to fulfill the original requirements for filtering, namely processing and bandwidth savings. - KD: Comments needed for the requirements, i.e., the requirements that were brought up need to be added. - Conclusion not reached. Will wait Jonathan's forthcoming proposal, will drive discussion on the list. --------------------------- - BINPIDF * Is this useful? - JR: When you define extensions, you need to have this stuff anyway. Why do we need this only, since there's no PIDF extension? It appears this is just something we learned, nothing to specify. - JR: If there is substantial amount of meta data that needs to be defined (content, rendering related attributes, etc.) and if this can be easily added to RPIDS, then it makes sense. As a standalone spec without any actual extension elements to PIDF, not really worth the WG's time and effort.