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: Some implementation drafts aside of RDFa



Bruce D'Arcus wrote:
>
> On Dec 12, 2006, at 8:32 AM, Svante Schubert wrote: 
...
>
> However, from the model perspective, you'd have to distinguish the 
> subject and the predicate. The meta:class attribute would just be 
> assigning a type to a subject, but the subject here would be unclear. 
> Maybe meta:about would be more appropriate?
What about having the union of all meta:class as the subject?

>
>> All elements with @meta:class="foo" are of the same semantic and 
>> define an area, which is not related to the XML hierarchy.
>> In this special case - representing an alternative to a start & end 
>> tag - this area is a sequence of content, but it might be as well 
>> clustered all over the content.xml.   
>
> The one problem is that I'm not really sure I'd call this an "area" 
> formally.
>
> For example, let's say we have a list:
>
> <text:list meta:about="event-1">
>   <text:li meta:property="http://ex.net/event#participant";>Jane 
> Doe</text:li>
>   <text:li meta:property="http://ex.net/event#participant";>John 
> Smith</text:li>
> </text:list>
>
> The items in the list are not one object (area) from a model perspective.

We all want a generic approach for metadata (whatever this means for 
each one of us)... Don't you think it would be most generic, if we would 
make no assumption of the used metadata in the content.xml at all? But I 
must admit, this might not be close related to the RDFa approach as RDFa 
gives a lot of information of metadata in the content.

After a discussion with Michael and Lars, let me bring in some other 
implementation details than RDFa.

There are various implementations.
The earlier used is adding the meta:class attributes for each element, 
which has meta data. more than one metadata is attached to the same 
element, the attribute value might be a list of space separated values.
Another approach is quite similar to the first, but uses user given 
names as attribute names in conjunction with the meta namespace: 
'meta:participant'.
And the third is adding to each ODF element which has meta data an 
xml:id and bundle these with an indirection similar to the XForms 
binding to RDF.

<text:list xml:id="meta1">
  <text:li xml:id="meta2">Jane Doe</text:li>
  <text:li xml:id="meta3">John Smith</text:li>
</text:list>

Note: If you want mnemonic xml:id values, there should be certainly an 
API to set them, but this is currently out of scope

In the new meta.xml, let's call it xmeta.xml, we have a binding element 
similar to the XForms binding, forming the various xml:id's to a set.

<meta:bindings xml:id="binding1">
    <meta:binding nodeset="content.xml#xpointer(id('meta1'))"/>
</meta:bindings>

<meta:bindings xml:id="binding2">
    <meta:binding nodeset="content.xml#xpointer(id('meta2'))"/>
    <meta:binding nodeset="content.xml#xpointer(id('meta3'))"/>
</meta:bindings>

Where binding1 and binding2 would be the subject of the RDF.

Question: How is validation being added? If I want to ask if for example 
to document being an invitation has the required data and location?

Beste wishes,
Svante.






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