Sounds good. My only question is about the "propagate change" approach. Does
it really require iteration, or is it just one big query? i.e.:
begin
delete {?person v:email '[email protected]'}
insert {?person v:email '[email protected]'}
from {all user's graphs}
where {?person v:email '[email protected]'}
end
On Wed, Aug 24, 2011 at 5:33 PM, Iain MacNeill <[email protected]> wrote:
> Including the items discussed in our recent gathering, here is another
> breakdown of the flow/process during updates to context values.
>
> It is broken up between Specific/Individual ("Connector") contexts, and
> "All About Me" aggregator contexts.
>
> Note: This does not attempt to identify specific systems, but rather
> defines the flow of logic in general. Also, this does not go into detail
> regarding the connector synchronization process, but just references it.
>
> *Editing of Specific / individual ("Connector") context values:*
>
> - When simple scalar values are updated by the user:
> - Begin Transaction
> - the change is immediately pushed to persistent storage.
> - No Errors: Commit Transaction - else Rollback and display error
> state
> - For complex values, a modal dialog is presented to the user
> with all of the relevant context attributes displayed with their current
> values and 'Ok'/'Cancel' buttons.
> - If the user either closes the tab or the browser, a browser level
> alert box will be presented requiring the user to confirm the loss of
> data.
> - When the user clicks on the 'Ok' button:
> - Begin Transaction
> - changes are pushed to persistent storage.
> - No Errors: Commit Transaction - else Rollback and display
> error state
>
>
> *Editing of "All About Me" aggregator context (Addresses, Payment Cards,
> etc) values:*
>
> - When a simple scalar values are updated by the user:
> - The user is presented with a dialog (TBD) which specifies
> (possibly: number of contexts to be changed, list of contexts to be
> changed)
> allowing them to confirm or cancel the update before it occurs.
> - If user confirms change should occur:
> - Begin Transaction:
> - Call method to propagate changes across user's contexts (see
> below).
> - If no errors are returned from call:
> - Push "All About Me" context attribute value change to
> persistent storage.
> - If update successful, then commit transaction.
> - Else rollback transaction - display error state.
> - Else Rollback Transaction - display error state
> - For complex values, a modal dialog is presented to the
> user with all of the relevant context attributes displayed with their
> current values and 'Ok'/'Cancel' buttons.
> - If the user either closes the tab or the browser, a browser level
> alert box will be presented requiring the user to confirm the loss of
> data.
> - When the user clicks on the 'Ok' button:
> - If something has actually been changed:
> - Begin Transaction
> - Call method to propagate changes across user's contexts (see
> below).
> - If no errors are returned from call:
> - Push "All About Me" context attribute value change to
> persistent storage.
> - If update successful, then commit transaction.
> - Else rollback transaction - display error state.
> - Else rollback transaction - display error state.
>
> *Sequence to propagate a change across all user's contexts:*
>
> - Begin iterating the list of user's control template contexts:
> - (At any point during the process, if an error occurs - processing
> will halt and the error returned.)
> - If current searched context is a simple attribute and updated
> attribute is simple, then:
> - If current searched context attribute/value matches original
> updated attribute/value, then
> - Push updated attribute value to persistent storage.
> - NO MATCH: proceed to the next.
> - If current searched context is a complex attribute and updated
> attribute is complex, then:
> - Compare all old attribute/values of the edited complex attribute
> against the current searched context, if all are equal then:
> - Update the individual attribute values that have changed to
> match the new updated values.
> - NO MATCH: proceed to the next.
>
>
> - Proceed to the next retrieved context
>
>
>
> On Fri, Aug 19, 2011 at 5:43 PM, Paul Trevithick <[email protected]>wrote:
>
>> Iain,
>>
>> I have a suggestion for how the context editor should work. It may well be
>> what you and Valeska (and Tom and...) were already thinking. If fact, it may
>> already be what we've coded in some cases! But let me describe it to you
>> quickly and get your reaction...
>>
>>
>> - Editing modality
>> - There are no "Edit" vs. "non-Edit" modes (such as Apple
>> AddressBook uses)
>> - If the user wishes to edit a simple attribute (e.g. gender) then
>> they just edit that attribute's widget
>> - If the user wishes to edit a complex attribute (e.g. an address
>> with street, postalCode, locality, etc. subcomponents, or a set of
>> online-behavior:interest attributes (as we are doing today)) the UI
>> pops up
>> a modal dialog box ONLY for the purpose of editing this one
>> complex-valued
>> attribute (e.g. array of p:InterestTopics, v:Address, v:Name, etc.)
>> - The attribute and both its old and new values are retained for
>> use in cross-context update (see below)
>> - If it is a simple attribute, this is one value
>> - If it is a complex attribute then all of the old values of the
>> "sibling" attributes are retained. For example if the attribute was
>> a v:adr
>> (with an instance of v:Address as its value), and if the user
>> changed the
>> value of the v:postal-code attribute from 02467 to 01234 then any
>> other
>> "sibling" attributes/values would be retained. These sibling values
>> might be
>> the values of v:street, v:locality, v:region and v:country.
>> - Saving
>> - It saves data to persistent storage after the user has completed
>> the edit operation as described in the simple and complex cases
>> mentioned
>> above
>> - Abandonment
>> - If the user is in the middle of editing a complex value and
>> closes the tab of the portal / context editor it pops up the dialog box
>> attached to this email below (copied from Google Docs)
>> - Cross-context update
>> - After any attribute of a p:Person in any context is edited, the
>> editor searches EVERY other context of this user to update that same
>> attribute of every p:Person found.
>> - If it is a simple attribute and the "old" value of the attribute
>> matches the old value of the attribute in the context the user was
>> editing
>> (see "modality" above) then replace the old value with the new value
>> that
>> the user entered
>> - If it is a complex attribute that was edited then the same
>> attribute (e.g. v:postal-code) will be updated if the following
>> conditions
>> are true:
>> - The old value of this v:postal-code matches the old value that
>> was retained during the editing of the original context by the user
>> - The old values of the sibling attributes (v:street,
>> v:locality, v:region and v:country) match the old values of these
>> sibling
>> attributes in the original context edited by the user
>>
>>
>> A couple more thoughts about cross-context editing:
>>
>> - I glossed over some complexities/recursion involved when the
>> "sibling" attributes are themselves complex. Since we don't have any
>> actual
>> cases of this, this wrinkle is only theoretical.
>> - I didn't mention how cases of multi-valued attributes should be
>> handled. This is a very real case we need to handle: the
>> online-behavior:interest attribute usually has multiple instances of
>> online-interest:InterestTopic as values. So the question is how to
>> represent
>> the "old" value(s) of interest. Should we only propagate the edit if ALL
>> old
>> values match? Well the answer is clearly no. We need only to remember
>> whether we are adding or deleting a value. When we go to the other
>> contexts
>> we should (a) only add the value if it isn't already present (which in RDF
>> isn't allowed anyway) AND if that value is explicitly mentioned as an
>> allowed value by the template of the context (see new Attribute class and
>> "allowedValue" attribute here [1]) and (b) only delete the value if it is
>> present
>>
>>
>> I've written this all very quickly. This is deserving of a wiki page. In
>> fact the cross-context attribute update should likely be broken out from the
>> other (much simpler) points. I'll try to get to that next week.
>>
>> Paul
>>
>> [1] http://wiki.eclipse.org/Template_vocabulary
>>
>>
>
_______________________________________________
higgins-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev
