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

[Patrick Durusau <patrick@durusau.net>]

Dennis,

Let me jump to your last concern first, that it is a dramatic breaking
change.

And your point would be?

That poor design has an afterlife until replaced by some wholly other
design, which has its own problems? Which persist until they are
eventually replaced? 

If we are talking about a new version, a 2.0, not a 1.* release, why not
have breaking changes?

One of the reasons why a number of changes were delayed for ODF-Next was
to preserve backwards compatibility for ODF 1.2. OK, we've done that. If
some implementers want to only produce ODF 1.2 software, that's their
choice. 

This particular case may not get enough of a benefit to justify the
change but that is a different question from holding up the talisman of
"dramatic breaking change." 

Hope you are having a great day!

Patrick

PS: I like your suggestion of NCName better than my xml:id, presuming
that we can have *one* targeting system. It just isn't clean design to
have a multitude of ways doing the same thing.


On Tue, 2011-01-18 at 14:16 -0800, Dennis E. Hamilton wrote:
> I think you will run into trouble where the previous use of the name is not restricted to an NCName that is capable of being an IDREF.  There are new uniqueness requirements and schema validation cases that come up with such a move as well.
> 
> Furthermore, the uses of the names that are actually references may refer to targets that are not in the same file, and if the target is to be of type ID (that is, an xml:id), we have to change the referring instance of the name from a different file into an IRI.  (Styles are an obvious case of this but I suspect there are others.)
> 
> Furthermore, use of xml:id is going to run the risk of collisions where there is and RDF metadata file that makes reference to an element via its xml:id and the implementation not being designed to preserve that possibility let alone be aware of it.
> 
> Finally, this is a dramatic breaking change.  Considering how peculiarly the few cases were handled in ODF 1.2 (where we were talking about attributes of type ID), I have no confidence in a blanket change of this magnitude.
> 
>  - Dennis
> 
> PS: My druthers, before it is too late to close this door, would be to avoid using xml:id for anchors that are part of the document structure that stitches together elements of an ODF document.  Instead, use NCNames (not ID or IDREF) for such connections, leaving xml:id as arbitrary targets into document for use by other applications, in-document RDFa, separate RDF metadata, etc.  This eliminates the uniqueness-among-all ID problem for structural cross-references and has xml:id be the only ID-valued attribute.
> 
> 
> 
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> Sent: Tuesday, January 18, 2011 12:06
> To: office
> Subject: [office] OFFICE-3311 - Identifiers - review and consolidate identifiers and references to identifiers
> 
> 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 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.
> 
> 2) Localization requires only changing the display string, not internal
> pointing mechanisms.
> 
> 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 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