RE: [office-collab] How to define restrictions: was 'Convergence of proposals'

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I want to point out that manufacturing attribute names is also a very weird namespace behavior and it is especially strange from wanting to have some sort of controllable schema.  How do we document a namespace like that?

I don't think that is fatal, but we need to get rid of the fabricated attribute names.

One can simply have a generic ACT:attribute-change (using ACT as the namespace binding for Advanced change Tracking, whatever that turns out to be) attribute that provides an ID (via URI or IDFREF) for some out-of-line element that is the collective attribute-change history for this particular element instance.  That could have any amount of element content to say what the attribute change progression was and who did it when, etc.  Clearly, the stuff there has to be within the limitations that the schema for the particular element has in terms of attributes, which ones are required, which ones are optional, which ones can't occur together and which ones are dependent on the presence of others (all flavors of which arise in the ODF Schema), so there has to be a way to treat joint changes to the attribute set as single operations.

 Even at this level, we can see that an use of gct that is blind to the ODF schema can get into all sorts of trouble, and it won't know what to do with foreign attributes in an element at all unless the particular implementation has built-in knowledge of some foreign attributes as part of its acceptance of extended ODF documents.  But non-recognized foreign attributes will have to be dealt with somehow (usually by being ignored) and any change-tracking involving non-recognized foreign attributes will have to be eliminated somehow if the element is touched in a processor or someone wants to inspect this particular change-tracking by some means in a processor that does not recognize those attributes.  (I don't mean for forensic purposes but in some visually recognizable observation of the effects with a way to see how those effects arose as part of changes not-yet-accepted.)  Also, there will be implementations of ODF documents that treat ACT:attribute-change as a non-recognized foreign attribute and may not notice it regardless in a non-recognized foreign-element start tag and that must be taken into consideration.  

Change tracking that changes the start tag of an element to be a different local name is pretty uncommon.  I don't think that can happen in ODF, although it is routine to change end tags and to add end tags somewhere beyond the ending point of a change (insertion or deletion).  So I don't think element-name changing will have to be dealt with as part of ACT on the attributes of an element.  

There might be some changes where there is a relationship between attributes of the element and what the element content is and that might be messy with regard to maintaining validity of the document.  That has to be checked for.  I can't think of a case off hand but I think there may be some cases, especially where content is switched from in-line to out-of-line based on an attribute pattern, and the out-of-line method can be peculiar (use of DDE with a filter, for example).   This means there has to be synchronization of the attribute change and content changing in some cases, if such changes are permitted as ACT trackable.

BOTTOM LINE

We have to have a scheme that is not allowed to start from an invalid (extended) document nor can it result in an invalid (extended) document.  There need to be some fail-soft measures in place, perhaps.

We need to look at requests that there be a history of accepted changes, not just provisional ones, but that may not be anywhere close to an ODF 1.3 provision.

NOTE TO SELF

Add handling of foreign elements and attributes to the kind of cross-cutting interactions that need to be dealt with in any comprehensive approach to change-tracking, even if only implemented selectively or modularly or whatever.

 - Dennis

-----Original Message-----
From: John Haug [mailto:johnhaug@exchange.microsoft.com] 
Sent: Tuesday, April 26, 2011 11:26
To: office-collab@lists.oasis-open.org
Subject: RE: [office-collab] How to define restrictions: was 'Convergence of proposals'

My concern was a general one – that the comments on the last call about using schema or conformance classes were made in passing and details around whether that is sufficient may not have been fully considered.  I’d rather hoped that an implementer or someone more familiar with RNG would have offered some thoughts to tease out whether the general concern has specific manifestations.

 

Core question:

Would it be sufficient for schema to allow any attribute on specific elements to get GCT treatment and reasonable for each application to have to interpret the per-attribute CT markup to determine whether the tracked change is something that app supports (or supports tracking changes to)?

 

 

Top of my head, trying something simple with tables initially to illustrate the point.  If someone has a better example, please jump in as that will help the discussion.

 

Assume an application supports protecting table cells but not tracking changes to whether a cell is protected.  A tracked change to cell protection might look like this:

 

Original

Modified

<table:table-cell table:protected="true">

<text:p>A</text:p>

</table:table-cell>

<table:table-cell ac:change001="ct1,remove,table:protected,true">

<text:p>A</text:p>

</table:table-cell>

 

If the application supports CT for tables, it can’t just ignore the ac:change001.  It would have to parse it, decide whether it can handle tracking a change to that attribute, then do something appropriate.  Needing to decide on an per-attribute basis whether to apply or ignore change tracking seems a bit burdensome on an implementation.

 

In this particular case, the rest of the element is OK as is, so it just has to ignore the fact a change was tracked.  A better example might complicate this if something else in the element (or, worse, elsewhere in the doc implied by something in the element) couldn’t be taken at face value, but I’m not intimately familiar enough with ODF schema to know whether there are such cases.

 

Does that help illustrate the concept?

 

John

 

From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
Sent: Saturday, April 23, 2011 2:35 AM
To: office-collab@lists.oasis-open.org
Subject: [office-collab] How to define restrictions: was 'Convergence of proposals'

 

John,

Perhaps we could explore this one a bit further, I am not sure where/whether there is a problem/disagreement here.

Please would you suggest a real example of a change that needs to be tracked (perhaps one of the use cases?) and the rules that you believe need to be encapsulated in order for an editing application to be sure to understand it.

Then we can look at how these rules could be defined - otherwise we are discussing in the abstract rather. 

I think this is what Rob was suggesting in drilling down a bit in specific use cases to focus our attention on identifying the real issues - boil the ocean a drop at a time perhaps! This use case could be the workhorse one perhaps, per Rob's email 'Suggestion:  Focus initially on a small number of use cases'.

Thanks,
Robin

On 21/04/2011 18:38, John Haug wrote: 

> Yes, I believe so: some restriction is needed, possibly in the form of conformance classes or simply in the RelaxNG grammar.

And I’ll repeat from the call my concern that this may be insufficient.  Restricting the tracking of general types of changes to certain elements is helpful, but it still allows, for example, any change of that general class to be tracked on the element.  So, restrictions at levels such as schema would allow tracking of changes to any attributes on a set of elements, not just ones that represent intentional changes the user has made to the conceptual document objects represented by those elements.

 

What do the other experts here think – am I misunderstanding or is this a valid consideration?

 

..snip  

John

 

 

..snip 

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php