OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: [office-comment] shorter XML representations for the values ?


One solution for the boolean issue would be to harmonize
our office:value-type attribute with XML Schema datatypes,
at least for the common overlap in types.
XML Schema's boolean type allows lexical forms to be one of:
true, false, 1, 0.   That would allow a more compact form.

Do you know if the next specification will take this efficient boolean values representation into account ?

 > By using a base 62 representation (symbols by increasing weight :
 > 0-9 letters, a-z letters, A-Z letters), the value of the
 > "office:value" attribute becomes "z3wBXdvb".

That would add considerable complexity on ODF processors,
 The nice thing about using XML Schema datatypes is
that they are well known and supported in tools.
In particular, validating parsers can apply additional constraints.
So a use could easily write a script,
using just off-the-shelf XML tools,
to confirm that all cells in an ODF spreadsheet have values between -50 and 1000.
But if values are encoded like "z3wBXdvb"
then it would require custom coding to make sense of that value.

One way to think of this:  adherence to well-known standards
provides an efficiency of its own,
in terms of understanding, compatibility with existing tools, etc.
But it might not be the optimal in terms of run-time performance.
An alternative here -- which we've talked about before -- would be
to have a canonical binary encoding of ODF.

I don't think that standardisation is the end of the innovation. If you have enough time to make the "off-the-shelf" tools compliant with the new specification, then a shorter representation of values would be a benefit for everyone.

I don't think the binary encoding would be a solution for long term storage. As you said, XML provide benefits like validation, etc.

I think a shorter value representation is a good trade-off between the use of the generic XML language/tools and the need of efficiency.

If you think about the increasing cost of the energy, then a more compact XML would be a benefit in the data centers, desktop computers, etc.


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