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] data-typing


Hi Bruce,

Bruce D'Arcus wrote:
> So I looked at the existing data-typing attributes in ODF. 

Thanks for pointing out the data type problem.

I assume that we have roughly two weeks till we have to finish, 
therefore it is important to get all the things on the table 
(mailinglist) and get them straight for the editors.
(BTW Patrick seems to be still on the road, an updated draft will be 
sent out early next week.)

> My conclusion is that while we can reuse the office:value-type attribute 
I assume that we have to extent the possible set for office:value-type 
as well.
The current is:

<define name="valueType">
   <choice>
       <value>float</value>
       <value>time</value>
       <value>date</value>
       <value>percentage</value>
       <value>currency</value>
       <value>boolean</value>
       <value>string</value>
   </choice>
</define>

> we need a new generic value attribute; perhaps we call it just 
> office:value?
Yes, the name of the office:value attribute vary on the corresponding 
type. ODF exist the following office:boolean-value, office:date-value, 
office:string-value, office:time-value, office:value.
 
>
> The reason is that the current set of value attributes are fixed, and 
> specific to the defined data-type. That does not provide us enough 
> flexibility.
>
> Also, IIRC, the existing list of data-types is extensible? If yes, 
> that's good, because I think we need that. But if we have that 
> extension, then we them to be in the form one would expect: either a 
> URI or namespace-qualified QName.
>
> So I would suggestion this for the latter attribute:
>
> office-value = attribute office:value { text }
I think we have here in general three different design possibilities:

   1. Reusing the existing attributes (office:value and
      office:value-type) and expanding their attribute value set, on our
      new element context.
   2. Reusing the existing attributes (office:value and
      office:value-type) and using new attributes (e.g. meta:value and
      meta:value-type) if we leave the existing set
   3. Introducing new attributes (e.g. meta:value and meta:value-type),
      but reusing as well the attribute value set of the existing
      attributes (office:value and office:value-type)

Today I tend to solution three, but I am curious about the opinion of 
Patrick and Michael as editors of the ODF spec.

I will start to work out some RelaxNG for the third solution, which 
should be able to be easily adapted to one of the others.

I wish all a nice week-end,
Svante


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