Minutes from first part of 2nd Tuple meeting 10jun2003 (9:?? edt - ~10:30edt): [The meeting was already in progress when I started taking these notes.] JR raises issue of wanting to relate tuple with geoloc with tuple of cell phone call state. Henning discussing tuple linkage. Nesting rejected as unworkable. Possibilities are linkages with foreign keys in tuples, or separate join records. Jon P proposed a 3rd way: an attribute that identifies the device. Could be included in multiple tuples, which then implicitly causes them to be associated. PK brought up distinction between tuples input to aggregator and those output from aggregator. Brian was concerned that without more crispness about the def of tuple this just makes things worse. JR proposed that this is a filtering problem: the presence agent has a bunch of raw material to work with, for which multiple kinds of views might be computed: a device centric view, a media centric view, an application centric view, ... A given client may need a particular type. He proposed this could be handled by filtering - the filter picks the kind of view the watcher wants to consume. Henning was concerned that it is infeasible to provide every kind of view that anybody might want. Brian still bothered by possibility of multiple views. Henning says it doesn't matter - the watcher acts the same way regardless, and doesn't care. JR is concerned about automata. Example, send an IM when not on a call. Gave an example where presentity rendered presence separately per language rather than per device - left automata confused. He felt his concept of filtering would solve this. Henning still doesn't see the problem - it is just a set matching problem. Biggest issue is when there are multiple matches, but that is a separable problem. JR gave another example: user has mobile phone and video phone, but exposes it in a media centric way. Somebody that wants to talk to a mobile phone cannot do so. PK indicated that the filtering is a good thing, but not necessary - can be done later. Henning related to db theory: a table (tuples) need at least as many rows as there are independently variable properites. If you reduce the number of rows by merging, you lose information. Brian says his presence agent works this way. It takes presence for multiple sources, and generates a single tuple representing the result for any given watcher. PK proposed that the concept that each tuple guarantees the validity of every combination of attributes is key to know. There may be cases where you don't want to guarantee that (especially as output from aggregator). Ought to have the tuple indicate if it provides this guarantee or not. [I stopped note taking here. Looking back I find that I have written down remarkably little. I don't know if that is a defect in my note taking, or if it reflects reality.] Forwarded from Keith (Thanks again to Keith and Paul for taking notes this time). ----------------------------------------------------------- Notes of 2nd tuple discussion, 2nd session continued at 15:40 UK time. Discussion of whether to use Jon's slides. BR: Need document that explains tuples to people building watchers explaining all options. JP: SIMPLE could add a markup document to PIDF that explains this. If not understood (by non SIMPLE system) that would be ignored. Jon cannot see why this creates a practical problem for Brian. Cannot understand what is broken. HS: Already have ability for simple devices with limited screen real estate to render these in different ways. Have to improvise means of representing the data where necessary. BR: Killing example. Send 3 presence documents to watcher from different presentities, device view, service, presentity view. How are they sorted out. HS: Not a problem. Each has URL. Will create a rendition to user of the view of each URL. JR: Maybe should restrict ourselves to elementary document, and leave the complex view to further study. HS: Illustrate by some examples and general rules. If you do this, this is what you are going to get. PK: Not sure device publisher and agregator have same view on this. JR: Interested in how do you publish documents that are able to provide this correlation information. HS: Guidance on things that simplify publishing and others that make it more difficult. Some simple rules that the compisitor has to do. Rule: if merges two roles with contrdictory properties - option a: union - option b: result becomes undefined. JR: This does not work well in a system which has a much more detailed knowledge of what each row represents. HS: Thinks this still fits the row model. Only twist is that simple restriction that only rows with same URI is relaxed so that different but related URIs can be merged. JR: HS: BR: HS: Like spreadsheet pivoting. Taking all the rows that have one property and combining them. JR: What is the primitive or elemental view of what is being described. What limits what can be done. HS: Need to define which combining operations are valid for columns. BR: Are you making assumption that elementary is device? HS: Not necessarily. Single device can however have multiple elementary rows. HS: Elementary: Every instantiated property that is enumerated has to exist. BR: Can deal with this if elementary does not have much status in the world. Providing watchers cannot be built that only accept elementary. HS: That is not intention. This is being expressed from the compositor view. PK: Worried about where Brian is going. Having to build separate preferences for separate tuples. HS: For certain columns there is no sensible entry that you can have. On-hook has little meaning for an IM. PK: On-hook could be a service view or device view. HS: Goes back to elementary row definition. Open view or closed view. BR: Little sceptical of leaving it unbounded. JR: What is it? BR: Defining of tuple in this row/column sense. JR: Doesn't think it changes anything, merely a different way of thinking about it. PK: Should use tuple the same way as mathematics and database theory. HS: Only have the URI scheme and the note that are in PIDF. JR: Need to ensure that a baseline PIDF compliant entity can actually do something with the model. Possibly a BCP document BR: Or an examples document. If leave ill defined then need examples or BCP to show how it is used. HS: Not prohibited that multiple things have same URI even without note. Watcher can still combine. BR: Need a document. Has to be documented somewhere. JP: Writing document is not a prerequisite for finishing the protocol work. However should not stop this document happening. RS: Output of this design team is belief that this document should exist. Not part of design team to write it. Given this do we have a sufficient characterisation of tuple in order to allow publish work to continue. BR: We need precise words in order to be able to proceed. RS: How do we get there? Definitions to date have satisfied a large subset of this community. Does not yet know what precise means. JP: Need to commit Hennings row and column stuff to written text. Not sure that Brian is going to get what he wants. BR: JP: A tuple needs to be able to tell you what it is. BR: Is this an IANA register of tags? HS: BR: There is no such thing as a database viewer, and this is the problem with the unbounded view Henning is proposing. Anything just gives the raw data, rather than the database structure. HS: Compositor creates a view of the database. Watcher runs select operator on this and out puts a table rendered as he wishes. RS: Is anybody else in same problem space as Brian. JR: There are valid databases where the client has to understand the scheme in order to make the query. RS: Henning to write down the mode. Jonathan to capture idea of using filters to constrain what the watcher is going to get. See if this solves Brians problem. JR: Write down specific things that an automata needs to be do. Jonathan will do this. HS: Not arguing for arbitrary. Arguing that there is a generic master definition, and the only thing that can happen is a view is taken of this. RS: Need to move this conversation into an email format, and then based on that decide when the next discussion is. Discussion closed at 17:05 UK time.