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: [issue] split object literals


Last week I flagged one issue to resolve (concern about broken 
subject-object association), and here I'd like to flag a related one: 
the problem of what to do with in-context object literals that get 
split across document nodes.

The case that Svante and Michael seem to be concerned about is this:

<text:p>
   <text:span meta:about="http://ex.net/x"; meta:property="ex:title">Some 
</text:span>
</text:p>
<text:p>
   <text:span meta:about="http://ex.net/x"; 
meta:property="ex:title">Title</text:span>
</text:p>

So the idea here is the user means to highlight that content as a 
single property of the specified subject.

To be clear, then, this is a narrow problem specific to object 
literals. I doubt, for example, that right now ODF allows a link node 
to span paragraphs, and if that's true, I would the same constraints 
would apply to objects that are resources.

The first point I'd like to make is that this then suggests that the 
ideas Svante and Michael have been proposing are not in conflict with 
the RDFa-like approach, but supplements to that. Perhaps they have been 
intending that all along and it has just escaped me, but I hope we can 
clarify this.

Second, as I mentioned to Michael off-list, this problem is 
conceptually quite similar to a recent discussion in the TC about 
handling split-lists. If I am right about that, I would suggest that we 
treat it as a general issue rather than one specific to metadata.

I see two reasonable solutions:

1) the in-context approach

Use an attribute like object:id. One could use the same attribute for 
lists as well, and so have a general solution to this problem. Where a 
node has such an attribute, a processor would know to look for one or 
more additional nodes with the same attribute value, and to treat them 
as a single object (list, or property value).

2) the package approach

This is what Michael and Svante have been talking about, where you'd 
have pointers to the parts in some separate XML chunk. You'd need 
xml:id attributes on the property nodes to do this association.

Both of these approaches would still need the meta attributes; they are 
just two approaches to solving a very narrow problem specific to using 
them in an office file format.

Is the above characterization fair?

Bruce



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