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

[Patrick Durusau <patrick@durusau.net>]

Bruce,

Bruce D'Arcus wrote:

>
> 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.
>
Sorry, you lose me with the loss of granularity argument.

I think we are both assuming that some markup is going to be placed in 
content.xml to delimit the text that is the focus (to avoid saying 
subject) of the metadata. Yes?

Suppose that I want to attach metadata to some arbitrary part of text in 
a <p> element. If I use <span>someText</span> to enclose it, how have I 
lost granularity?

> 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).
>
See above.

>> 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?
>
Just as having notes in a separate file works. There is a marker in 
content.xml that is the "target" of the metadata held in a separate 
file, just as we do notes now.

That the metadata is held in a separate file is an implementation detail 
and not something that would be apparent to the user.

> ...
>
>> 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.
>
Hmmm, but styles are removed, yes? Stored only in styles?

Not really sure about your visible/invisible argument. Why should 
presentation make a difference in terms of the internal structure of the 
document?

> 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.
>
Can you be a bit more explicit? Is this the issue of entering 
information twice?

If so, that to me is again a question of presentation. Whether the 
citation content is stored as metadata and "presented" to the user as 
inline content or no, really is a presentation issue. The user only has 
to enter it once and get the display they want. What more could they ask?

> So I don't think there's anything yet that logically excludes option 2.
>
Well, no, but I wasn't arguing that "logic" excludes option 2. And while 
not an implementation requirement or even a "new" requirement, I do 
think we should consider the impact of our proposals on processing of 
ODF documents. Having mixed models for metadata (some inline, some in 
meta.xml) seems to be a particularly bad choice to me. Granted we may 
encounter cases where that cannot be avoided but I haven't seen one, yet.

I was suggesting some form of xml:id as a way to avoid messing around 
with adding attributes to content.xml whatever metadata we want to 
associate with elements or content. Just seems like a clean solution to 
me. Opinions will no doubt differ. ;-)

I realize that RDFa is supposed to make it easy to use RDF with XHTML 
but I don't think models for authoring XHTML are really relevant for ODF 
applications. Different format and different considerations in play.

Hope you are having a great day!

Patrick

> Bruce
>
>
>
>

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