Re: [office] Proposal for cursor position

[Michael Brauer <michael.brauer@sun.com>]

Paul,

Paul Grosso wrote:
> At 13:01 2003 12 08 +0100, Michael Brauer wrote:
> 
>>Dear TC members,
>>
>>an action item for me is to create a proposal for the representation of the cursor position within one ore more document views.
>>
>>As agreed in the 24 Nov con call, there should be an element that marks possible cursor positions in the content. I propose to use an <text:view-mark> here that can occur within <text:p> and <text:h> elements. <text:view-mark> has a single attribute "text:id" that takes the unique id of the mark. <text:view-mark> simply marks a text position so that it is referencable from somewhere else within a file. The element has to be ignored if such a reference does not exists.
>>
>>Within the application specific settings, I propose to add an config item set with the name "office:view-settings". The only config item supported is an indexed map with name "Views". Each of the map entries supports the string properties "ViewId" and "CursorPosition". "ViewId" contains the name of the view. It allows applications to specify additional properties for the same view within other config item sets. "CursorPosition" contains the id of a <text:view-mark> element within the content.
>>
>>An example for this could be
>>
>><office:settings>
>> <config:config-item-set config:name="office:view-settings">
>>  <config:config-item-map-indexed config:name="Views">
>>   <config:config-item-map-entry>
>>    <config:config-item config:name="ViewId"
>>                   config:type="string">view2</config:config-item>
>>    <config:config-item config:name="CursorPos"
>>                   config:type="string">view2pos</config:config-item>
>>   </config:config-item-map-entry>
>>   <config:config-item-map-entry>
>>    <config:config-item config:name="ViewId"
>>                   config:type="string">view1</config:config-item>
>>    <config:config-item config:name="CursorPos"
>>                   config:type="string">view1pos</config:config-item>
>>   </config:config-item-map-entry>
>> </config:config-item-set>
>>
>> <config:config-item-set config:name="ooo:view-settings">
>>  <config:config-item-map-indexed config:name="Views">
>>   <config:config-item-map-entry>
>>    <config:config-item config:name="ViewId"
>>                   config:type="string">view2</config:config-item>
>>    <!-- more application specific items for "view2" -->
>>   </config:config-item-map-entry>
>> </config:config-item-set>
>></office:settings>
>>
>>
>><text:p>My Test<text:view-pos text:id="view2pos"/>.</text:p>
>><text:p>My Test<text:view-pos text:id="view1pos"/>.</text:p>
> 
> 
> 
> Since the cursor can be almost anywhere in a document, the text:view-pos
> element would need to be allowed anywhere by the schema in use.  I know
> XML DTD's don't allow inclusions.  Do XML Schemas and/or RelaxNG?  If
> we can't represent the allowable location of text:view-pos via a DTD,
> do we care?

Whether the cursor can be anywhere in the document or only within 
paragraphs probably depends on the kind of view you have. In a source 
view, in an XML tree view, or in any other XML related view, the cursor 
can in fact be anywhere. In the view that office applications normaly 
offer the cursor must be within text, or it is a certain object that is 
selected. My proposal was related to office application views only, but 
I agree that other kind of view might be a use case we want to or should 
cover as well.

> 
> If we do, then I don't see how we can use an element to represent the
> cursor position.  (Arbortext's Epic uses processing instructions to 
> represent the cursor position and other view-related information.)

Maybe a processing instruction is the better solution. However, this 
would mean that we reference a processing instruction from an element. 
We might also use a processing instruction only. This would be a clean 
concept from the XML point of view, but since we didn't use processing 
instruction so far, this would be a completly new concept within the 
open office format.

Maybe we should consider to find a solution for the whole cursor 
position topic in the 2nd TC phase.

> 
> paul

Michael