fields clarification

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

For discussion today on the fields:

We're really left with a few questions:

1) what's the semantics of the field? If we have a URI for it, what 
does that URI refer to? Recall existing proposal is now using 
meta:about, and so implicitly assumes the URI defines the subject of 
the field. My impulse is to say that's wrong, and that it refers to the 
object.

2) where does 1 get encoded, and how? Right now, it's inconsistent. A 
simple case of one reference gets encoded in content, anything more 
than one (like *some* citations) gets encoded exclusively in RDF/XML. I 
hate that kind of inconsistency.

One solution (favored by Stante) is to allow fields to be nested. E.g.:

<text:meta-field field:type="http://odf.org/Citation";>
(
   <text:meta-field meta:about="urn:isbn:34879823">Doe 
1999</text:meta-field>,
   <text:meta-field 
text:field-style="http://ex.net/short";>2001</text:meta-field>
)
</text:meta-field>


The other solution is the one I suggested on list of having a source 
and body child and individual references within the source. I prefer 
this approach because a) it's consistent (makes no difference if you 
have one or ten references resources in a field), and b) it's 
(coincidentally) consistent with how MS does fields in OOXML (so 
interoperability will not be hard). Also, with the nested approach, one 
gets into awkwardness like having to rearrange the actual element 
content if you need to sort the resource labels differently (as you do 
in citations).

But ultimately I want a good, clear, consistent proposal, so that's my 
primary goal. I don't want the demands of citations to hold things 
back, but I do believe it's a good real world test that we have the 
details right.

Bruce