Re: [office] OFFICE-3311 - Identifiers - review and consolidateidentifiers and references to identifiers

[Patrick Durusau <patrick@durusau.net>]

Andreas,

On Tue, 2011-01-18 at 14:39 -0700, Andreas J. Guelzow wrote:
> On Tue, 2011-01-18 at 13:05 -0700, Patrick Durusau wrote:
> > Greetings!
> > 
> > For identifiers we use text:name, style:name and other various
> > mechanisms.
> > 
> > http://tools.oasis-open.org/issues/browse/OFFICE-3311
> > 
> > Since names are sometimes displayed
> 
> These names should really not be displayed. For display purposes we have
> attributes such as style:display-name.
> 

So are you suggesting we drop display of such name and replace the
display name with style:display-name?

> >  and yet must also server as
> > identifiers, that means some names are subject to restrictions, such as
> > no spaces, that other names are not. 
> > 
> > I propose that we use xml:id as the universal identifier for ODF
> > elements. All pointing is made to an xml:id.
> > 
> > Where necessary for other purposes, such as display to users, the
> > various *:name attributes can be retained but for use as names.
> > 
> > I see three advantages to this change:
> > 
> > 1) Implementors have to implement one pointing mechanism, not several.
> 
> This reason would have worked for 1.0. To make this change requires
> implementors to support both mechanisms plus to handle possible
> conflicts.
> 

You mean legacy files? 

Not really, depends on the application. 

If you mean a full-featured, supports every draft or version of ODF ever
published for all capabilities, yes. 

If you mean a "lite" application that only supports meta entry for
document that are surrounded by frames, possibly not. It is only
generating ODF documents and need not know or care what other generators
of ODF documents may or may not do. 

> > 
> > 2) Localization requires only changing the display string, not internal
> > pointing mechanisms.
> 
> As I said above for display we have style:display-name and friends.
> > 
> > 3) Depending on the internal processing model, implementations do not
> > have to store names used as targets. It is sufficient that the
> > pointer/target is generated when the document is saved.
> 
> I don't see how that differs between the two models?
> 

Ah, good point.

I should have observed that where users supply names that are used as
targets (as in display), then the application has to preserve the name
*as given.*

As opposed to simply creating the pointer/target relationship and then
when saving the file, generating an id for both the pointer and target.
Need not be the same one as when the document was read. 

Hope you are having a great day!

Patrick

> Andreas
> 
> > 
> > I am willing to make a list of the elements with attributes that point
> > to other elements, the nature of that pointing mechanism and any other
> > use that is made of either the pointer or target. Along with suggested
> > language deprecating the current mechanisms. (I would prefer to delete
> > it but suspect some transition time has to be allowed for existing
> > applications.)
> > 
> > Hope everyone is having a great day!
> > 
> > Patrick
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
>