Re: [office-metadata] xml:id and attributes

[Bruce D'Arcus <bdarcus@gmail.com>]

On Dec 13, 2006, at 7:56 AM, Patrick Durusau wrote:

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

It does, with the caveat, of course, that you are only able to label 
resources within the content, and that those resources are about the 
document proper (no referencing of external resources as subjects 
within the document).

In other words, you do lose granularity with this approach.

To repeat what I earlier said, we have two choices:

1) no metadata in content.xml

2) some metadata in content.xml (the hybrid RDFa/RDF/XML approach)

There is no other option, and each of them have trade-offs.

So let's talk about those trade-offs rather than constantly bring me in 
new requirements to discount one of these arguments. What Svante has 
been arguing option 1, while I and Elias have been arguing a way to 
option 2.

But if option 1 is (or can be) a little simpler, it's also more limited 
(which might be fine as a first step; don't know).

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

Yes, this is the granularity I mentioned. For example, say John has 
some references to prescriptions, diagnoses, and patients in his 
document. It might be valuable for him to right-click on one of those 
pieces of content (the patient "Jane Doe") and be able to get 
additional metadata about them.

I'm not really sure how you'd do that without the inline information?  
This is the critical question, really. How would you propose that would 
work Patrick?

...

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

So you are advocating option 1 above. That's fine. Let's discuss the 
compromises in the call.

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

The way I think of it, inline metadata is by definition about visible 
content, so analogous to styles. That ought to not to be required to be 
removed.

But certainly invisible metadata ought to be, and so ought to be 
separate from the content.

Also, I think the citation case (the field) shows the value of some 
metadata being in-content.

So I don't think there's anything yet that logically excludes option 2.

Bruce