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] custom-defined schemas

Hi David,

I just wanted to thank you for taking such an intense interest in the 
file format specification.  Your comments are  really informative.  They 
will be read with great interest and discussed.  Although you've hit on 
so many different areas it might take some time to reconcile discussions 
with our current agenda.  I did want to thank you though, and let you 
know that we are reading your comments and giving everything serious 

We recently approved adding XForms and SMiL to the specification.  I 
hope you'll take the time to factor that into your comments.  I'm 
particularly interested in your comments regarding XForms and the EU 
requirement for "custom-defined schemas". 

For those who are interested, i found David's personal web site at: 

Thanks for your contributions and interest David, and welcome to the fray,

Gary Edwards
Redwood City, California USA
A fellow Christian

David A. Wheeler wrote:

> According to "European Commission's IDA TAC Publishes
> Recommendations on Open Document Formats", June 17, 2004
> (http://xml.coverpages.org/ni2004-06-17-a.html),
> the IDA Expert Group and IDA TAC recommended that:
> "The OASIS Technical Committee considers whether there is a need
> and opportunity for extending the emerging OASIS
> Open Document Format to allow for custom-defined schemas."
> At least in theory, it shouldn't be hard to allow for
> data in arbitrary XML schemas; simply define some element
> to contain such data.  E.G., "<xmldata> ... </xmldata>".
> There would also need to be a way to define their
> schemas, by including one of the several ways to define
> schemas (e.g., DTDs, XML Schema, Relax-NT).
> Of course, there's no point in doing this unless
> applications can actually USE this.  So, here are some ideas:
> * Word Processor - Each nesting turns into a style.
>   You should be able to edit the material, and on save
>   restore it back to the XML format (using styles to determine
>   what to restore it back to).
> * Database/Spreadsheet -  Walk down through the nesting,
>   identify the likely fields, then display and let user select.
>   But that should only need to be done once - after that,
>   the schema itself (or some auxillary data) should record
>   what the "correct" fields are.
> Another idea -- that's not in conflict with those above --
> is to embed an XSLT processor.  The XSLT processor would
> specify how to get the data in and out of the other format.
> The idea of being able to edit arbitrary XML formats as
> a word processor with embedded styles has its appeals,
> since that'd allow easy editing of other formats
> (e.g., DocBook).  It's not clear if the other issues
> are really worth it or not; I'm just trying to provide
> what I hope are helpful ideas and suggestions.
> I wish you well..!
> --- David A. Wheeler

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