OASIS Open Document Format for Office Applications (OpenDocument) TC

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 -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Newcomb Number: 1

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

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 >

On Tue, 2011-01-18 at 17:12 -0700, Patrick Durusau wrote: > 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? I don't know what you mean. We already have "style:display-name". Only in the absence of that attribute style:name is used for display purposes. > > > > 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 see style:name as an internal identifier and style:display-name as the user visible name. > > > > > > 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? Most implementations are trying to read files from future versions of ODF as well as from older ODF versions. > > 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 we want to have full interoperability that should be the normal situation. > > 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. Of course things are always easy for generator-only applications. > > 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.* In that case the name should be stored in something like "style:display-name". Andreas

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 -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Newcomb Number: 1 --------------------------------------------------------------------- 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

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

Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 07:00:35 PM: > > 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? > I'm not sure that we have decided whether ODF-Next is ODF 1.3 (backwards-compatible release) or ODF 2.0 (a more ambitious update). The reason I called it "ODF-Next" originally was to avoid taking a stand on that question. But I suppose we can only defer that decision for so long... -Rob

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. > [ ... ]

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. > > > [ ... ] >

On Tue, 2011-01-18 at 19:43 -0700, Patrick Durusau wrote: > Dennis, > > OK, I see where I jumped the track so to speak. > > My assumption is and has been that ODF-Next = ODF 2.0. Six months to ODF 2.0? Like Dennis, I thought we were talking about ODF 1.3. Andreas This is a digitally signed message part

Andreas, On Tue, 2011-01-18 at 20:47 -0700, Andreas J. Guelzow wrote: > On Tue, 2011-01-18 at 19:43 -0700, Patrick Durusau wrote: > > Dennis, > > > > OK, I see where I jumped the track so to speak. > > > > My assumption is and has been that ODF-Next = ODF 2.0. > > Six months to ODF 2.0? Like Dennis, I thought we were talking about ODF > 1.3. > No, if we are doing CSDs every six months, working towards a release in two years (Michael's estimate), which accumulates up the CSDs to that point, why couldn't that be ODF 2.0? Not saying it would be, entirely the TCs decision but two years of CSDs to do a point release of corrections seems a bit slow. Particularly since moving quickly to standardization is alleged to be a feature of the OASIS process. >From my personal point of view the entire point of the ODF 1.2 exercise was to make changes, if deemed necessary and useful by the TC, *easier*. That doesn't mean we need to make any particular change but to enable changing where there is a real benefit to the change. Personally I like the idea of working towards a non-backwards compatible version. In part because new approaches are judged on their own merits and not their compatibility with existing code. But, as Michael has observed this morning, that is something that can only be decided on a case by case basis. So, without regard to the labeling, ODF 1.3 or ODF 2.0 or some other moniker, I will try to assemble the information for changes that I think would be useful. Hope you are at the start of a great day! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Newcomb Number: 1

On 19.01.2011 12:28, Patrick Durusau wrote: 1295436484.26257.4247.camel@ratatosk.home.org type= cite > Andreas, On Tue, 2011-01-18 at 20:47 -0700, Andreas J. Guelzow wrote: On Tue, 2011-01-18 at 19:43 -0700, Patrick Durusau wrote: Dennis, OK, I see where I jumped the track so to speak. My assumption is and has been that ODF-Next = ODF 2.0. Six months to ODF 2.0? Like Dennis, I thought we were talking about ODF 1.3. No, if we are doing CSDs every six months, working towards a release in two years (Michael's estimate), which accumulates up the CSDs to that point, why couldn't that be ODF 2.0? Right, my assumption was two years from now. 1295436484.26257.4247.camel@ratatosk.home.org type= cite > Not saying it would be, entirely the TCs decision but two years of CSDs to do a point release of corrections seems a bit slow. Particularly since moving quickly to standardization is alleged to be a feature of the OASIS process. If it gets entirely incompatible, then the next version should be called ODF 2.0. But we may call the next version ODF 2.0 even if it remains largely compatible. 1295436484.26257.4247.camel@ratatosk.home.org type= cite > >From my personal point of view the entire point of the ODF 1.2 exercise was to make changes, if deemed necessary and useful by the TC, *easier*. That doesn't mean we need to make any particular change but to enable changing where there is a real benefit to the change. That's a possible approach. But we are at the beginning of the development of the next version. If we agree now that the next ODF version gets incompatible, then it may happen that many proposal that we develop get incompatible, simply because they could. It may also happen that the proposals for which we enabled incompatibilities never make it into the specification. That would be bad. Michael -- 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

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