xml:id and attributes

[Patrick Durusau <patrick@durusau.net>]

Greetings!

First of several posts on our recent discussion of metadata attributes.

It occurred to me this morning that while we have discussed the general 
need to suggest adding xml:id to elements in ODF 1.2, there is a fairly 
compelling reason to do so in the metadata context.

Consider John Madden's use case:

<someElement>blah, blah, Patrick Durusau, blah, blah</someElement>

A physician want to add information to the string "Patrick Durusau," 
such as patient, etc.

One way to do that is to provide a metadata attribute on say the <span> 
element that would enable them to do so.

But, that means that either the attribute is going to have to be fairly 
general or we are going to be in the situation of adding attributes as 
ODF evolves.

On the other hand, if we add xml:id to all elements, doesn't that 
provide us with the basis for attaching any arbitrary information to the 
element without having to change the attributes on the elements? In 
other words it gives us a fixed anchor as the basis for adding 
additional attributes (in a sense, not literally) to any element.

Granted that I take it as implied that John wants the added information 
to be "inline" but that is a matter of presentation or UI and not a 
literal requirement on the resulting markup. That is to say that the UI 
can literally present the added information as though it actually exists 
"inline" in the document.

We do need to consider the limitations on xml:id as a datatype, which 
forces some oddities in terms of what can be an xml:id. We may wish to 
have an odf:id which has the characteristic of being unique but without 
the limitations of xml:id.

Moreover, xml:id supports our use case of separation of metadata from 
the content.xml file.

Note that I would suggest that we only use this mechanism for adding 
metadata to elements.

Consider John's use cases again: We want to sweep all the files for 
metadata added by physicians. If we allow users to choose where that 
metadata is going to be located, the search might have to occur in two 
locations: content.xml and the meta file. Really more efficient to 
simply decide that the metadata will *always* be in the meta file, which 
avoids the overhead of processing content.xml and provides an 
opportunity to write software specifically for that purpose.

I have been reading OOXML and they use the same xml:id to link various 
elements together in files in the package. What I have yet to puzzle out 
is the need for a relationships file that is described in prose as 
limiting the elements than can have relationships to elements in the 
equivalent of the content.xml file. I suspect it is meant as the 
expression of a limitation they decided to not represent in the schema. 
But, the xml:id to xml:id mechanism appears to me to have some merit. 
Noting that if one sweeps the metadata files and prepends a document 
identifier (to avoid conflicts between xml:ids which are unique only on 
a per document basis) that you automatically have a link back into the 
content.xml file. I haven't finish reading OOXML so I don't know if they 
suggest that as a reason for this feature or not. If they do, we might 
have to cite them as the source of the idea.

Actually for all the heat of the discussions on OOXML, I know a number 
of rather gifted people at MS who have really good ideas. Unfortunately, 
none of them are in charge of making corporate policy (or maybe that is 
why they aren't).

Hope everyone is at the start of a great day!

Patrick

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!