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..


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.

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]