[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-3788) Make xml:ids stable over the lifetime of a document
[ http://tools.oasis-open.org/issues/browse/OFFICE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32324#action_32324 ]
Dennis Hamilton commented on OFFICE-3788:
-----------------------------------------
@Andreas - I meant the XML element, since that is all that an xml:id can be attached to. I completely agree that "it's complicated" to know what it means for the element to endure (whether or not that is not the form of the document that is the basis for emitting a persistent form in ODF), and this is going to be very implementation-dependent.
I want to add something to this and my post to the list (https://lists.oasis-open.org/archives/office/201302/msg00013.html) on the same subject:
1. There are products that support ODF that will never have a way to preserve xml:id as part of the endurance of what is essentially the same element between input and output. That is because the products operate by conversion to and from an internal structure that has nothing to do with ODF and are designed for the full-fidelity processing of a different "native" format. The obvious historical cases are WordPerfect and Microsoft Office. I am certain there are others. At the moment that includes Gnumeric, LibreOffice, and Apache Office too. Those *might* do something about "enduring elements" but it seems inappropriate to impose that. It would be better if there was a compelling use case that developers of those products found essential to support.
2. There are custom arrangements where the produced document is legitimate ODF 1.x but the consumer only supports the features that producers emits. The producer is ODF compliant. The consumer might be, depending on how it swallows ODF features it doesn't support. Invalidating that producer by imposing a specific format requirement on any use of xml:id ID values is not beneficial. Of course there can be workarounds, but one wonders why we force someone to fix something that is not broken and for no meaningful benefit.
> Make xml:ids stable over the lifetime of a document
> ---------------------------------------------------
>
> Key: OFFICE-3788
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-3788
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: New Feature
> Affects Versions: ODF 1.3
> Reporter: Patrick Durusau
> Assignee: Patrick Durusau
> Priority: Blocker
> Fix For: ODF 1.3
>
>
> Currently, xml:ids (19:914) are not required to be stable over the lifetime of a document. So long as an application maintains the links established by use of xml:ids and serializes those, it is free to generate or save xml:ids it encounters.
> That approach was adopted before the first TC meeting on 16 December 2002. (https://lists.oasis-open.org/archives/tc-announce/200211/msg00001.html) A few days before that, PC Magazine reported its editor's choice for the year:
> "Dell Dimension 8250 - 2.8-Ghz Pentium 4, 512 RDRAM, 7,210-rpm 200GB hard drive, ATI Radeon 9700 Pro graphics card, DVD-ROM and DVD-RW drives, two USB L1 and six USB 2.0 ports, one FireWire port, 18-inch LCD. (Brown, Bruce. PC Magazine. 12/3/2002, Vol. 21 Issue 21, p102. 9p. 4 Color Photographs, 9 Charts.)"
> As of December, 2011, PC Magazine reported its editor's choice as:
> "HP Pavilion p7-1167cb - 3.1GHz Intel Core i5-2400 processor, 8GB of RAM, 7200-rpm 1TB hard drive, AMD Radeon HD 6450 (512MB) discrete graphics card, DVD+-RW, four USB 2.0 ports, audio-in and -out, a mic jack, Ethernet, and VGA and DVI-D video outputs, 25-inch LCD monitor (HP 2511x). (Shoemaker, Natalie. PC Magazine. Dec2011, Vol. 30 Issue 12, p1-1. 1p.)"
> I suspect this is one of those decisions that was influenced by our appreciation of the hardware capabilities implementers would face while implementing ODF. The change in "average" hardware is enough to merit reconsideration of the stability of xml:ids.
> Benefits from stable xml:ids:
> 1) Stable reference points for change tracking
> 2) Detection of non-change tracked deletions (operation pointer no longer has a target)
> 3) Centralized change tracking (request only operations after timestamp or xml:id sequence)
> 4) Changes to changes by different applications detectable but not resolved by ODF.
> Not to mention that stable xml:ids would be an incentive to fix all the referencing in ODF 1.3 to use xml:ids and not names, etc.
> I have proposed using a 32-bit number below as that allows addressing up to 4,294,967,295 items. There is a lot of experience with compressing 32-bit numbers. Should we bump that up to 64? Just to avoid revisiting the issue any time soon?
> I prepended odf to the string to meet the requirements of NCNAME in XML Schema Part 2, Datatypes, http://www.w3.org/TR/xmlschema-2/#ID
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]