Re: [office-metadata] Define a Mechanism to Associate Metadata with Content?

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

On Sep 13, 2006, at 9:56 AM, Patrick Durusau wrote:

> Moreover, for example, both ODF and MSXML have sections, but they have 
> different content models. From what I have been told, MSXML does not 
> allow sections within sections, while that is possible in ODF.
>
> If I convert MSXML -> ODF, ok, but then if I edit the document in ODF 
> and embed sections within sections, I have no way to map that back to 
> MSXML.

OK, but the "moreover" here is in not a metadata use case ;-)

> If I had the metadate for these sections as having originated in 
> MSXML, then my ODF application could restrict the use of sections so 
> that I have a clean conversion back to MSXML.

I was thinking based on our earlier conversations with Florian that it 
would be helpful just to have some property-value flags to signal how 
to handle certain behavior. I can see that easily in what I've been 
envisioning.

But adding a whole layer of complex xpath stuff to actually embed 
conversion logic within ODF documents seems like a different matter.

> That there are many ways to do conversion has no relevance to the 
> question of whether this is "metadata" or not.

Only in the sense that it's still not clear to me that this is within 
scope of "metadata."

> The question is whether structure (XML markup) is data in an XML 
> document instance or is only the content within XML markup data.

Thanks for this clarification. It's helpful.

> I take the position that both markup and content are data in the sense 
> that both can have metadata associated with them.

I take a different view. The objects we are concerned with are the 
objects that users deal with:

	documents
	figures
	tables
	citations

... and depending how granular we want to get sections, paragraphs, 
spans.

It is definitely not some XML node.

> There is no loss in having a general mechanism that can address both.

If there is no loss, then perhaps we can make sure the requirements 
reflect that? I vote against including this requirement explicitly, or 
perhaps rephrasing it if we can come to some more clear consensus.

[...]

> Note I was not suggesting that we *do* an interoperability mapping but 
> provide a standard mechanism for anyone who wanted to do one.

OK.

>> I'm really not following the use case tie-back here Patrick.
>>
> The use case that was contribued by Florian if I am not mistaken 
> raised the issue of conversion.

Yes, but I was never really clear what he was saying (why I didn't 
include it), and thought he recently clarified that it has a somewhat 
different (more narrow) requirement.

Bottom line on this one: I'm confused ;-)

Bruce