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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: Re: [office-metadata] Binding proposal


Bruce,

Bruce D'Arcus wrote:
> 
> Thanks for the suggestions Michael.
> 
> A couple of comments:
> 
> On Mar 20, 2007, at 11:26 AM, Michael Brauer - Sun Germany - ham02 - 
> Hamburg wrote:
> 
>> So, it is a dilemma. On the hand, we need stable and unique ids to be 
>> able to share metadata.
> 
> The issue is that this is not only (or I think even necessarily mainly) 
> about sharing metadata. It's about being able to make any statements 
> about a document.

I'm not sure of I do understand that. All documents on my hard drive 
have an id (the path in file system). If I don't make my system 
accessible to someone else, and if I do not run any tools that collect 
metadata from documents, why do I need an additional id that is stored 
in the document? Why should I care about that at all, if I don't need it?

Sure, I may decide that I want to share the document later. But in this 
case, I may add an id when I make this decision.

> 
>> And on the other hand, we cannot ensure that these ids are maintained 
>> properly, but need the help from our users, that again have to 
>> understand what the id is for.
>>
>> So, to get out of this dilemma I would like to suggest is we make the 
>> use of global and unique ids optional. That is, the user itself may 
>> decide whether she or he want to share the metadata in the document. 
>> If the user wants to share the metadata, then the document gets a 
>> unique id, and the user itself is responsible for making sure that the 
>> document is only edited by applications (or users) that are aware of 
>> the id and understand what it is about. Of cause, office application 
>> may and should assist the user in maintaining the id.
>>
>> If the user does not want to share the metadata, then the document 
>> does not get an id, and the metadata in the document does not get a 
>> meaning outside the scope of the document.
> 
> I like the idea of giving users control over this sort of thing, but I 
> don't think the question of sharing is equivalent to that of 
> identification. For example, one could have a URI for the document that 
> was stable and unique, and still decide you don't want to share the 
> metadata.

An optional id allows that, doesn't it?
> 
> I really don't think the document URI should be optional. I think what 
> should be optional is if a user would like to use their own (say http) 
> URI, rather than some default urn:uuid. It should also in general be 
> optional whether they want to change the URI (with warning notes!).

Allowing othere URI than urn:uuid seems to be very reasonable to me.

But who shall warn? Office application may do so, but text editors 
won't. ODF editing is not restricted to office application. And even if 
it would, who would understand that warning. Nearly no office 
application user will read the ODF specification or will even know it 
exists, and only very few user will read the online help. Users will 
take the default action, and they will look for ways to get rid of the 
warning. If that's not possible they may even decide to not use the 
product any longer because it is to difficult to use.

And even if someone develops a custom ODF application, I have some 
doubts whether she or he will care about ids unless they are really 
required in a certain use case. Only people that really need that id and 
do understand how it works will care about it. But they will do so 
regardless whether it is optional or not, because they have understood 
the problem. All others, will just ignore the id, or will put in 
anything, just to get rid of a warning.

So, the only thing you can force by making an id mandatory is in my 
opinion that you get an id. But you cannot force that this id is an any 
way meaningful or meaningfully maintained. But on the other hand, those 
who understand the problem and need that id will add it and will 
maintain it, even if it is optional.

Having that said: The only choice we in my opinion have is to have ids 
in all documents, where most of them are unmaintained and therefore most 
likely not meaningful, or to have ids only in those documents where they 
most likely are maintained only, and to have no id (or the location of 
the document only) for all other document. My preference actually is the 
later, because it allows you to differ between the document with (most 
likely) maintained ids and those with unmaintained ids. But that's 
really just my personal preference, and since I did not follow the 
discussion closely, there may actually things I have overseen or I may 
not be aware of.

Michael

> 
> Bruce
> 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


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