OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]