Thead summary (earlier: summarizing recent suggestions)

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi group,

Here is a summary of the outcome of this thread, please correct me if I 
misunderstood or forgot something.
<Note: Uncertain passages start with "2Decide" or "2Clarify">

1)
We are going to use @xml:id as specified by the W3C on the following ODF 
elements:

images
paragraphs
headings
tables
table-cells
bookmarks
metadata elements

We decided that text:span as a volatile element, which had been created 
for style information, should neither become parent of an xml:id nor RDF 
attributes, instead a new metadata element will be created.
/2Decide:
There had been several options "text:meta", "text:metadata", 
"text:metadata-label and if the name shall contain the term "field", 
then "text:meta-field" would be an option.
I personally tend to "text:meta" for it's brevity similar to "text:span".
/
The problem of relative links will be resolved by referencing to chapter 
Section 17.5 of the ODF specification and provide the extension to allow 
base IRI within the package. The following wording was proposed:

"The base IRI of the document is the one specified by [the 
manifest.xml], or the location of the package, if the manifest does not 
specify a base IRI. A relative-path reference (as described in §6.5 of 
[RFC3987]) that occurs in a file that is contained in a package has to 
be resolved exactly as it would be resolved if the whole package gets 
unzipped into a directory at the location specified by the base IRI."

We are going to provide an informative note in our proposal of the 
possibility to use the W3C owl:sameAs attribute in RDF/XML to set RDF 
resources in ODF as equal even across document borders.

It is obvious - therefore I suggest to avoid an informative note - that 
the usage of @xml:base in RDF/XML will break the relative link to ODF 
element in the package, when @xml:base is not similar to the new package 
base IRI of the manifest.xml and - for the case there is no such base 
IRI - is not similar to the document location.

2)
Instead of using meta:text-set, we allow the pair of attributes 
"rdf:about" & "rdf:property" on the same set of ODF elements, which were 
chosen already for the xml:id attribute.
/2Clarify:
The RDF object of a RDFa element is the literal from the concatenation 
of it's descending text nodes./

/2Clarify:
Instead of the earlier suggested attribute "meta:impl" on the meta 
elements, we currently discuss an attribute to express the type of the 
element.
It is meant as a hint for ODF applications to trigger the right plug-in, 
Bruce gave the example
<field:field field:type="http://ex.net/Citation""; xml:id="0874801373"> 
foo</meta:field>

This seems to me like an IRI identifier for a ODF element being a RDF 
subject.
To give a similiar hint for RDF streams a similar mechanism should be 
used for the meta manifest file.
Therefore I propose that one stream might only have one type, but 
multiple streams can have the same type.
//
/3)
An existing abbreviation mechanism in ODF /(Any link to spec?)/*/ /*was 
proposed to be reused to shorten attribute values:
<meta:field xml:id="0874801373 xmlns:contact="http://ex.net"; 
field:type="contact:Contact">foo</meta:field>

/2Clarify:
Hereby the IRI will be replaced by a QName expression and a attribute 
resolving the namespace.
This abbreviation makes even more sense, when the 'xmlns:contact' would 
be moved from the same element to the usual namespace declarations in 
the root element.
By this we could save an enormous amount of space.
Does RDF/XML allow a similar approach? It would ease XPATH / XSLT usage, 
if we could do so.//

/
Have a nice evening,
Svante