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

[Patrick Durusau <patrick@durusau.net>]

Dennis,

OK, I see where I jumped the track so to speak.

My assumption is and has been that ODF-Next = ODF 2.0. 

Yes, there are a lot of issues that we need to deal with concerning ODF
1.2, but those are ODF 1.2 issues.

Apologies for not having been clearer. 

Nothing "broken" so much that xml:id would fix it, but if writing a 2.0
version, it is something that should be cleaned up. 

Hope you are having a great day!

Patrick

On Tue, 2011-01-18 at 18:17 -0800, Dennis E. Hamilton wrote:
> Two things:
> 
> 1. I am not talking about a 2.0.  I am considering 1.x only.  If the proposal is to have ODF 2.0 be next, all of our discussion about incremental CSDs and provisional implementation of features can go away, especially if we are proposing that 2.0 is to be a major new format representation, structurally at least.
> 
> 2. I am talking about the interoperable preservation of existing documents in a heterogeneous-platform world where not everyone is on the same version on the same day (and their existing documents certainly are not).
> 
> In that context, my question is what is so broken (not distasteful, but broken) that switching to xml:id would fix it, versus the incompatibilities and prospects for errors and new complexities that such a change raises?
> 
> If it isn't broken, however it might offend various personal sensibilities (and I have an abundance of those), let's deal with provisions of ODF 1.2 that are of greater concern.
> 
>  - Dennis
> 
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> Sent: Tuesday, January 18, 2011 16:01
> To: dennis.hamilton@acm.org
> Cc: 'office'
> Subject: RE: [office] OFFICE-3311 - Identifiers - review and consolidate identifiers and references to identifiers
> 
> 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
> [ ... ]
> > 
> > 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.
> > 
> [ ... ] 
>