Re: [office-metadata] Editing files post metadata

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi group,

after some discussions with Michael, some further informations came up, 
I wanted to share with the group.

Please find them in line..

Svante Schubert wrote:
> Hi Bernd,
> 
> I fully agree, it is a good to separate these two requirements.
> Some comments in line.
> 
> Bernd Schuster wrote:
>> Hi Patrick,
>> thank you for bringing back the discussion on an emotional level on 
>> which constructive work can be done.
>> I agreee in what you are saying with one exception:
>> I propose to differentiate between the use case
>> 1)  of splitting of literals, which are tagged with metadata
>> and
>> 2) the use case, where a given plugin is missing.
>>
>> because the handling of a missing plugin is a more general problem 
>> which applies to many use cases, where content editing interferes with 
>> metadata concerns.
>>
>> Given the above use cases, 2 requirements can be defined, which from 
>> point of view should be added to our proposal
>>
>> 1) The splitting problem must be handled by the editing application in 
>> that it has first to recognize that some kind of inconsistency is 
>> going to occur and second it has to generate some kind of software 
>> event which might be processed by a piece of software (i.e. a plugin).
> In the first part we could define the splitting problem. That it might 
> happen by splitting the ODF element, related to metadata. This might 
> occur when:
> a) forced by user interaction independent to metadata (e.g. insertion of 
> a table in between)

A paragraph break is sufficient for this example.

> b) forced by user interaction when metadata have intersection (e.g. 
> three ODF elements (A, B, C). The content of A and B is equivalent to 
> one RDF literal, the content of B and C another RDF literal.
> The second part of your proposal might be no longer a requirement, more 
> an implementation advise and might be neglected.

c) forced by intersection with other information (for instance
hyperlinks, or style information. To explain this further: Text in ODF
contains many other properties except the future meta data. For example
hyperlinks, style information, bookmarks, reference marks, change
tracking information etc. All this information may exist simultaneously
and overlapping, and needs to be mapped to properly nested XML elements.
To solve this task, some information is not stored as a single XML
element, but as separate empty elements to denote the start and end
position of the information in the text. This avoids problems with
nesting of XML elements, but of cause makes it much more difficult to
get the text that actually carries the information. It therefore seems
to be no option for metadata. Anyway, if we already require that the
text that carries metadata is element content, then we should at least
provide the option to split it over several elements instead of
requiring that it is stored in a single one.


>>
>>
>>
>> 2) The use case, where a given plugin is missing must be solved by 
>> some kind of default plugin which is able to handle the software event 
>> adequately (Of course, one reaction of this default plugin can be 
>> warning the user. But this, for me, is not in the scope of this 
>> discussion.).
>> Maybe the requirement can be formulated like. "The user must be at any 
>> time aware of what impact his work has, or the application must 
>> provide mechanisms which ensure, that the consistency of the metatdata 
>> is guranteed".

That's difficult. Without a plug-in, the application can only display
RDF predicates and objects. These most likely will not be understood by
end-users, and she or here therefore will not understand the impact of
her or his work. The application on the other hand can ensure
consistency only by removing metadata, because it does not know what
operations make metadata invalid and which don't.

More intelligent behaviors can only be achieved by either linking the
meta data in different ways to the content (for instance ids and
classes) or by classification of the metadata as shown below.

> Although the fallback metadata handler (default plug-in) is not direct 
> part of our work (the proposal of an ODF extension for metadata), our 
> proposal could ease the work for ODF applications, by providing 
> flexibility and informations for later scenarios.
> In this scenario the default plug-in have to handle different types of 
> metadata - i.e. equal (e.g. ex:fullName) and additional (e.g. 
> ex:important) - in the same consistent manner.

Best regards,
Svante