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: Re: [office-metadata] Regarding the =?UTF-8?B?4oCcc3BsaXTigJ0gcHI=?==?UTF-8?B?b2JsZW0vdXNlLWNhc2U=?=


Hi Florian,

first good to see you back active on the list.  ;-)

With bookmarks you added a third valid approach representing metadata 
with the start / end tags. This proposal has the advantage that it is 
the best proposal from the Office point of view.
The document is being read from the office from the beginning to the 
end. When in the stream a 'start' appears, the office is aware of the 
meaning of the following items. No continuous interpretations of most 
likely more attributes, there are only two elements (start & end).
In other words, the start / end tag mechanism is fine for reading XML as 
a stream, e.g. SAX as it is being used by our filters.
Unfortunately it is a nightmare, when somebody uses other XML mechanisms 
as DOM or XSLT. Imagine you get via XPATH a XML node and you have to 
search for a possible start tag to see if you are part of some metadata. 
And this start tag can be anywhere ahead of the stream, not only in you 
ancestors.

I can not say, if this is a drawback for the usage with metadata, but it 
is some for the usage with XML techniques other than streaming.
What do the others think?

Regards,
Svante

Florian Reuter wrote:
> Regarding the “split” problem/use-case I must confess I don’t really see the problem/need.
>
> If I wanted to mark parts of a paragraph with metadata I would simple use structures which are there and attach and RDF statement to it.
>
> In the given use case I would use a bookmark and attach metadata to the bookmark.
>
> Bookmarks can start and end at “everywhere”. I really dislike the object:id approach.
>
> With bookmarks you can achieve the same thing as with object:id’s --- I believe.
>
> E.g. consider the ODF fragment
> <text:p >XXX <text:bookmark-start text:name="_MYBOOKMARK"/>MMMMM</text:p>
> <text:p >MMMM<text:bookmark-end text:name="_MYBOOKMARK"/> XXXX</text:p>
>
> We could then have an RDF statement like
> (bookmark::_MYBOOKMARK, my:mark, “Important”)
>
> Please note that bookmarks can be hidden. So we won’t event bother the user with RDF bookmarks.
>
> How we encode the above RDF statement is up to us. We can do inline like
> <text:p >XXX <text:bookmark-start text:name="_MYBOOKMARK" my:mark=”Important”/>MMMMM</text:p>
> <text:p >MMMM<text:bookmark-end text:name="_MYBOOKMARK"/> XXXX</text:p>
>
> or in a separate RDF stream. We only need to define a URI syntax to address bookmarks then…
>
> The bookmark approach for this special use case together with an external RDF stream would even provide backward compatiblity with current ODF readers, since they will preserve the bookmarks and preserve the external RDF stream.
>
> ~Florian
>
>   


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