OpenDocument - Adv Document Collab SC

Hi all, most of these issues have already been discussed by various members in different postings/calls but please allow me to sum them up as they are quite important from my point of view: 1) The issue of whether the scope of the elements/attribute of the GCT Proposal has to be restricted has been raised quite a few times and I think that there's kind of agreement on this, right? 2) If you restrict the GCT Proposal to some common user actions, there won't be that much of a difference between the GCT and the ECT Proposal from the application feature point of view. 3) The specification of the CT in the ODF spec has to be accurate and non-ambiguous. 4) We have to make sure that the XML won't get bloated, this applies especially to spreadsheet document where in theory all changed values and formulas could be tracked. 5) On the one hand we have to make sure that the complexity of the XML is kept within a reasonable range (see the list item merge example in GCT 6.15). So we should consider using insert/delete (see ECT Supplement 1) to avoid complexity. On the other hand the ac:change attribute in the GCT Proposal provides a handy means to keep the xml code dense (given that 1. is considered). 6) We have to make sure that interoperability with the Microsoft Office Products can be achieved (at least on the feature level). This holds true for the GCT Proposal, most likely this also holds for the ECT Proposal. Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment

Thanks for these useful notes, Frank. Comments below. On 20/04/2011 14:21, Frank Meies wrote: 4DAEDDE9.5060200@oracle.com type= cite > Hi all, most of these issues have already been discussed by various members in different postings/calls but please allow me to sum them up as they are quite important from my point of view: 1) The issue of whether the scope of the elements/attribute of the GCT Proposal has to be restricted has been raised quite a few times and I think that there's kind of agreement on this, right? Yes, I believe so: some restriction is needed, possibly in the form of conformance classes or simply in the RelaxNG grammar. These restrictions would ensure that only operations known by editing applications would be allowed. It has been suggested that an unrestricted mode also has use cases - I agree with this - and the key here would be to ensure that it is simple to convert from unrestricted to restricted. This should be the case: ignoring/deleting change history for a particular element should be a simple operation. 4DAEDDE9.5060200@oracle.com type= cite > 2) If you restrict the GCT Proposal to some common user actions, there won't be that much of a difference between the GCT and the ECT Proposal from the application feature point of view. From the application feature point of view, I think you are right, in the sense that both can record such changes. But we want to widen the scope of CT so we need to consider how each proposal moves on to do this - see also your comment 6 below. 4DAEDDE9.5060200@oracle.com type= cite > 3) The specification of the CT in the ODF spec has to be accurate and non-ambiguous. Agree - this is one of the big problems with the current CT, e.g. it wraps deletions in a way that is not well defined, and this is a reason why Microsoft could not implement it: as Doug said in his blog at the time, Each implementer must decide how to synthesize markup to make each piece of deleted content into well-formed XML, and then later €“ when it comes time to accept or reject the change €“ each implementer must make decisions about how to distinguish between the synthesized packaging and the deleted content itself. Unfortunately, the ODF specification doesn €™t provide much guidance on this complex topic. ( http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx ) 4DAEDDE9.5060200@oracle.com type= cite > 4) We have to make sure that the XML won't get bloated, this applies especially to spreadsheet document where in theory all changed values and formulas could be tracked. Yes, though short and non-ambiguous is not always easy to achieve! Apart from spreadsheets, there has been some concern on this front re ECT 'buckets' and the size of these. 4DAEDDE9.5060200@oracle.com type= cite > 5) On the one hand we have to make sure that the complexity of the XML is kept within a reasonable range (see the list item merge example in GCT 6.15). So we should consider using insert/delete (see ECT Supplement 1) to avoid complexity. On the other hand the ac:change attribute in the GCT Proposal provides a handy means to keep the xml code dense (given that 1. is considered). Yes. Insert/delete always looks simpler in XML (it is Level 1 in GCT) but for a user means that content is deleted and inserted where this has not been done. Simple/intuitive to a user is not always simple in XML. If content has not been deleted and inserted, why should the CT show a delete/insert? 4DAEDDE9.5060200@oracle.com type= cite > 6) We have to make sure that interoperability with the Microsoft Office Products can be achieved (at least on the feature level). This holds true for the GCT Proposal, most likely this also holds for the ECT Proposal. Yes. But as the features in Word and ODF applications are constantly changing, this is a moving target so CT needs to have flexibility to respond to changing needs. 4DAEDDE9.5060200@oracle.com type= cite > Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment -- -- ----------------------------------------------------------------- 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

>
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?
 
>
Yes. Insert/delete always looks simpler in XML (it is Level 1 in GCT) but for a user means that content is deleted and inserted where this has not been done. Simple/intuitive to a user is not always simple in XML. If content has not been deleted and
inserted, why should the CT show a delete/insert?
Again, let us recall from the April 12 call that specialization of the names of the change mark elements and/or elements within the text:changed-regions was
highly recommended to make it explicit to applications what user actions resulted in the change tracking markup.  Indeed, I believe this is the only context in which such specialization to support clarity for interoperability has been recommended.  The value
I see with this is that it combines the architectural simplicity of the insert/delete pattern with the explicitness of specialized element names, which I think supports clearer interop among implementations.
 
Again, is this invalid rationale?
 
>
Yes. But as the features in Word and ODF applications are constantly changing, this is a moving target so CT needs to have flexibility to respond to changing needs.
Actually, this is an interesting question.  Do we have a sense of how much the scope of change tracking support in common applications is evolving?  My sense
is that the set of document-centric user actions where change tracking is valuable is fairly well-defined and stable.  Of course, this question is more qualitative than quantitative, so I ??m curious what others ?? perspectives are.
 
 
John
 


From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]

Sent: Thursday, April 21, 2011 3:12 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Convergence of proposals


 
Thanks for these useful notes, Frank. Comments below.

On 20/04/2011 14:21, Frank Meies wrote:
Hi all,

most of these issues have already been discussed by various members in different postings/calls but please allow me to sum them up as they are quite important from my point of view:

1) The issue of whether the scope of the elements/attribute of the GCT Proposal has to be restricted has been raised quite a few times and I think that there's kind of agreement on this, right?
Yes, I believe so: some restriction is needed, possibly in the form of conformance classes or simply in the RelaxNG grammar. These restrictions would ensure that only operations known by editing applications would be allowed. It has been
suggested that an unrestricted mode also has use cases - I agree with this - and the key here would be to ensure that it is simple to convert from unrestricted to restricted. This should be the case: ignoring/deleting change history for a particular element
should be a simple operation.



2) If you restrict the GCT Proposal to some common user actions, there won't be that much of a difference between the GCT and the ECT Proposal from the application feature point of view.
From the application feature point of view, I think you are right, in the sense that both can record such changes. But we want to widen the scope of CT so we need to consider how each proposal moves on to do this - see also your comment
6 below.



3) The specification of the CT in the ODF spec has to be accurate and non-ambiguous.
Agree - this is one of the big problems with the current CT, e.g. it wraps deletions in a way that is not well defined, and this is a reason why Microsoft could not implement it: as Doug said in his blog at the time, "Each implementer must
decide how to synthesize markup to make each piece of deleted content into well-formed XML, and then later ?? when it comes time to accept or reject the change ?? each implementer must make decisions about how to distinguish between the synthesized packaging
and the deleted content itself. Unfortunately, the ODF specification doesn ??t provide much guidance on this complex topic." ( http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx )



4) We have to make sure that the XML won't get bloated, this applies especially to spreadsheet document where in theory all changed values and formulas could be tracked.

Yes, though short and non-ambiguous is not always easy to achieve! Apart from spreadsheets, there has been some concern on this front re ECT 'buckets' and the size of these.




5) On the one hand we have to make sure that the complexity of the XML is kept within a reasonable range (see the list item merge example in GCT 6.15). So we should consider using insert/delete (see ECT Supplement 1) to avoid complexity. On the other hand the
ac:change attribute in the GCT Proposal provides a handy means to keep the xml code dense (given that 1. is considered).
Yes. Insert/delete always looks simpler in XML (it is Level 1 in GCT) but for a user means that content is deleted and inserted where this has not been done. Simple/intuitive to a user is not always simple in XML. If content has not been
deleted and inserted, why should the CT show a delete/insert?



6) We have to make sure that interoperability with the Microsoft Office Products can be achieved (at least on the feature level). This holds true for the GCT Proposal, most likely this also holds for the ECT Proposal.
Yes. But as the features in Word and ODF applications are constantly changing, this is a moving target so CT needs to have flexibility to respond to changing needs.



Regards,

Frank

--

Frank Meies Software Developer
Phone: +49 49 23646 500
Oracle OFFICE GBU

ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle
is committed to developing practices and products that help protect the environment





--
-- -----------------------------------------------------------------
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

John Haug <johnhaug@exchange.microsoft.com> wrote on 04/21/2011 01:38:47
PM:

>
> > 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?
>

A specific example would be the value of an ID/IDREF. So long as the
values are consistent from a referential integrity perspective, an
implementation should be able to freely rewrite these values with
application-generated unique random identifiers. There are examples of
values that may change, but typically are not of interest to a user from a
change-tracking perspective.

-Rob

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: 91C4760493E4094B9871E5A496374DA23211E680@DF-M14-01.exchange.corp.microsoft.com type= cite > > 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

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

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

It has been mentioned that RNG is not suitable for constraining GCT as it is only possible to limit change tracking to specific elements and not particular attributes on those elements. One way to add this type of restriction would be to use schematron, which I believe can be embedded into RNG. Below are two examples of schematron rules, one that prohibits changes to a specific attribute on an element (implying that all other attribute changes are ok) and one that only allows changes to a specific attribute (disallowing changes to other attributes implicitly). These may not be constraints that we actually want to make but are used as an example of how such constraints could be defined. This rule forbids changes to the table:protected attribute on a table:table-cell: <rule context="table:table-cell"> <report test="@ac:*[tokenize(.,',')[3]='table:protected']">You are not allowed to track changes to the table:protected attribute on a table:table-cell</report> </rule> This rule ensures that only the text:style-name attribute on a text:p can be changed: <rule context="text:p"> <assert test="@ac:*[tokenize(.,',')[3]='text:style-name']">You may only change the text:style-name attribute on a text:p</assert> </rule> More advanced constraints could make use of extra information added to the change transaction definition. If the change transaction contained information on the change type, constraints could be made for each change type. For example, a change type of 'Move Frame' could be used to check that the only changes are to the svg:x and svg:y attributes on the draw:frame Tristan On 26 Apr 2011, at 19:25, John Haug wrote: > 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 -- Tristan Mitchell, DeltaXML Ltd "Change control for XML" T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK