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

[Michael Brauer <michael.brauer@oracle.com>]

Hi,

Breaking backward compatibility for sure is something we have to deal with carefully. Its worse to open a document in a format you think your applications understands, and all you see is a "format error", or an empty document.

But backward compatibility is not a simple "yes" or "no" thing. Documents may in general be backward compatible, but some particular features may not. For instance, if we add the new change tracking feature to ODF 1.3 (ie whatever we call the next version), it is likely that change tracking in ODF 1.3 documents is not understood by ODF 1.2 implementations. It may however be the case that the content of the document without the change tracking information is still understood.

A good but for sure not absolute measure may be if end users benefit from an incompatible change. In the case of change tracking they will benefit, because they get change tracking for many new objects. Vendors that implement ODF 1.3 may tell their users that they get these new option, but at the cost that change tracking is not understood by older applications. I believe users will understand that.

A change that may not be understood by end users is if we adapt all namespace URIs to http-URIs with an "1.3" as version instead of "1.0", although this from the pure ODF specification point of view may be justified. That's because end users do not have any advantage from this, and the impact of this change would be dramatic: Not a single bit of an ODF 1.3 document would be understood by an ODF 1.2 application.

Having that said: Patrick has shown interest in correcting something that in his opinion is broken. Since we have many names, the changes for sure won't be simple and we need to look at the impact this has regarding backward compatibility. But before saying "yes" or "no" we should give him and anyone else the chance to work out enough details that we can evaluate the pros and cons of such a change.

Best regards

Michael

On 19.01.2011 03:43, Patrick Durusau wrote:

1295405010.26257.4169.camel@ratatosk.home.org" type="cite">

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.

      

[ ... ] 

    

---------------------------------------------------------------------
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 

  

--

Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 | |
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle is committed to developing practices and products that help protect the environment