OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] The desirability of xml:id stability


On 02/04/2013 10:54 PM, Andreas J. Guelzow wrote:
On Mon, 2013-02-04 at 15:34 -0700, Patrick Durusau wrote:

On 02/04/2013 04:36 PM, Andreas J Guelzow wrote:
On Mon, 2013-02-04 at 14:30 -0700, Patrick Durusau wrote:

3) What I am missing is some evidence, other than your saying it, that
preservation of xml:ids is any harder than preserving any other
attribute value.

I understand implementations don't do the preservation now, but at one
time implementations didn't use XML either. Non-use doesn't mean that a
proposal is too difficult or unworkable.

Being able to reliably point into documents would be the next step
towards not simply getting document level pointers from a search engine.

Patrick, what would be an example of an arbitrary string attribute value
that is currently being preserved by at least some ODF
Is the "arbitrary" part a requirement?

That is there are plenty of specified attribute values that are
persisted. See any stylesheet attribute whose value is chosen by a user.

I don't know how that preservation is different from preserving an
"arbitrary" string?

But to amuse you, consider the <text:user-index-mark> which has the
attribute: text:string-value. 8.17 and 19.871.6, respectively.

19.871.6 reads: "The text:string-value attribute specifies text to be
displayed in an index."

So, I created a file, inserted a user defined string in the index,
created an index that shows the user-defined value.

Please open, edit (somewhere other than my index entry), save and re-open.

Does my arbitrary text still appear?

I would say it was preserved by the application. Yes?

Try it with OpenOffice first, but I suspect the same will be true for
some other implementations.

I wasn't thinking of a user visible attribute value. Obviously a
consumer/producer that supports this element will need to preserve the

But, the current conformance language for consumers is:
"It shall be able to parse and interpret OpenDocument documents of one
or more of the document types defined by this specification (see 3.3)
any of which are represented in packages, but it need not interpret the
semantics of all elements, attributes and attribute values."

So with respect to the text:string-value attribute it seems to me that a
conforming consumer need _not_ preserve that element, it can choose not
to interpret the semantics of that attribute.
Good point.

Perhaps one we need to revisit in ODF 1.3.

Not of much use to choose a conforming ODF application and it lacks something as basic as preservation of user-defined index entries.

My understanding of the xml:id proposal is that it goes well beyond that
by _requiring_ a conforming consumer/producer to preserve the attribute
value. Are we requiring this for any other attribute value?

See above, we may wish to tighten conformance to generate a basis for expecting particular capabilities for an ODF conforming application.

Much as with OpenFormula that defines "groups" of functions that are supported for particular conformance levels.

Perhaps the base level with be, support as much of anything as far as you like.

The next level will be support of basic office features that most users would want from an ODF application.

And so on.

Preservation could well be an issue for other attribute values in such a case.

Hope you are having a great day!



Patrick Durusau
Technical Advisory Board, OASIS (TAB)
Former 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]