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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: final updates


So the TC approved the metadata proposal in principle today (great!). 
We just need to do the remaining changes. I expect Svante and/or 
Patrick will do this with a change-tracked version of the submitted 
proposal.

Here's what I suggest:

1) I was fine with all editorial suggestions Svante posted, except for 
the ones about preservation of attributes and files. I'll deal with 
that issue below, but suggest we just make the other changes. That gets 
us 98% or so to done.

2) I suggested requiring xml:id on text:meta-field. I can't really 
think of any reason not to require it. Is that OK? This would require a 
schema change (see TC list post).

3) On preservation of xml:id:

I agree after the lengthy discussion on the main list and on the call 
today that this is a really tricky issue to define with any sort of 
precision that actually achieves what we want to achieve without 
unintended consequences. I would thus be fine with the following 
language:

"All implementations SHOULD preserve any xml:id attribute and its value 
when present on any of the elements listed in 1.4.3. If an applications 
changes an xml:id attribute value, it SHOULD update any associated 
bindings in the metadata manifest to maintain referential integrity."

As we discussed, the language of "should" is already fairly strong, 
basically requiring conformance unless there's an explicit reason not 
to do so.

We might want something similar for the metadata attributes (m:about, 
etc.).

4) on the non-modification statement:

"Metadata files should not be modified unless the content of the 
metadata file is changed."

Svante suggested dropping it altogether. I'd like something like this 
instead:

"All implementations SHOULD preserve metadata statements and their 
associated RDF graphs stored in the file package."

That's not quite right, but I can't think of anything better. It at 
least gets away from worrying about the specific structure of the 
files, and focusses on the content, and it make implementors aware of 
the issue even if they don't implement metadata support.

Bruce



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