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] Finding a common proposal..


Svante.Schubert@Sun.COM wrote on 12/05/2006 07:40:25 PM:

> Hi Bruce,
>
> Bruce D'Arcus wrote:
> > ...
> >>>
> >>> I don't like the "no redundancy" requirement (e.g. in the spec
> >>> "there shall be no redundancy") at all. By that logic, the citation
> >>> field could not have an author name or date (e.g. in-text content of
> >>> "(Doe, 1999)"),
> >> Indeed, no data blobs should be allowed. When parts of the blob are
> >> meta data pieces there is no chance to validate them against the
> >> content (aside of parsing the blob). No machine is able to see
> >> (easily) if the text is still consistent with the meta data.
> >
> > Why would the "validation" you note be a requirement for us? I mean,
> > if I say "personal names shall be represented with given names
> > initialized" then the rendered text will deviate from the metadata.
> > It's not only not a bad thing to allow that, but a good thing. Or
> > consider a blind user; how do you validate that sound is equivalent to
> > text?
> >
> Let us neglect the coding for a while and take your in-text content of
> the quotation "(Doe, 1999)" as an example.
> Imagine you have a quotation plug-in to exchange the type of quotation,
> therefore we need to mark "(Doe, 1999)" as a meta data area to mark it
> exchangeable. I guess we all agree on that. Of course you can say that
> this area is a semantic black box handled by the implementation of the
> plug-in. But as there might be many plug-ins and not always available
> those areas become a none-edit field. Editing these fields bring you
> into danger to become inconsistent.
> On the other hand, if you define "Doe" and "1999" as further areas of
> meta data, it would enable you to keep them consistent with any
> reference you have.
> Therefore consistency is the requirement you asked for.
>
> BTW I found an argument for the design decision, that all viewable
> content should remain in the content.xml. The reason: as multiple meta
> data might like to refer to it, we would otherwise end up with
> inconsistencies of data copies in various meta files as multiple plug-in
> would handle the data independently.

That is not correct. Just because the content is in the meta.xml doesn't
mean you have to duplicate it. A reference is enough. BTW, who was moving
"viewable content" to the meta.xml? If anything, I thought we had a content
attribute with machine-readable data in the context.xml not in the
meta.xml.

>
> I have to do some further research on RDFa before I answer the rest of
> your mail.
>
> Have a good night,
> Svante



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