Re: [xml-dev] PAX: Why OOXML and ODF are inadquate bases for a forwa

["Rick Jelliffe" <rjelliffe@allette.com.au>]

bryan rasmussen said:
> Well, is there anything in either specification which disallows
> documents unknown by the interpreting application inside the zip? I
> suppose there really couldn't be.
>
>
> IIRC where Open Office is concerned if you send it a format with
> extension X and X just happens to be a zip file with open office
> content then it will parse that just fine. I suppose however that
> would break down if I extension X happened to be the extension for
> Open XML  so I guess you couldn't just hack your way to what you
> wanted (supposing a Windows environment). By the way, pet peeve, why
> does MS name their standard Open XML when they have an OPENXML rowset
> provider for T-SQL
> http://msdn.microsoft.com/msdnmag/issues/03/10/XMLFiles/
>
> darn them.
>
> So how about the format being defined as such: XML resources using XML
> Catalog to keep them straight, A Pipeline, transformations, okay
> validations too.
>
> Execution of the program should allow you to specify security levels
> to keep the pipeline from accessing resources not in the package.
>
> Then the actual format the document data is in can be any number of
> such, as long as the pipeline and transformations can handle it, and
> the outputs can be whatever one wants to support in the .pax
> application. Or whatever extension you end up choosing.
>
> Cheers,
> Bryan Rasmussen
>
>
>
> On 8/13/07, Rick Jelliffe <rjelliffe@allette.com.au> wrote:
>> Neither ODF nor Office Open XML are adequate bases for a
>> forward-looking,
>> general-purpose office document format.
>>
>> This is because the needs for level-playing-field data-interchange and
>> the
>> needs for full-fidelity native formats are diametrically opposed and
>> *irreconcilable* by any single schema. Level-playing-field data
>> interchange requires a limitation of the documents to features supported
>> by generator and consumer, and some ability for graceful degradation.
>> Full-fidelity native formats require complete implementation of
>> product-specific features, which well may be more than hints added on
>> top
>> of a generic structure, but sometimes have to be in terms of the data
>> models of the particular application.
>>
>> Furthermore, office formats embody some idea of application type (a
>> "word
>> processor", a "spreadsheet") however in real life, only "follower"
>> applications fit into those moulds, while "leader" applications go
>> boldly
>> into new areras.
>>
>> For example, Adobe StructuredFrameMaker is a word processor but also a
>> structured document editor. Lotus has WP capabilities but also groupware
>> aspects. In Office, Word has desktop publishing, blogging and forms,
>> Powerpoint is moving towards simple 2.5D animation, Excel is moving
>> towards report-writing features.
>>
>> Furthermore, different users have different needs. Professional users of
>> equations, bibliographic information, etc. have different requirements
>> to
>> lay users. Why arbitrarily choose one when we can have both?
>>
>> What would a better approach be? To allow and encourage modularity and
>> plurality at the base level. Take advantage of ZIP to have multiple
>> versions of information items. A ZIP file can be both ODF and Open XML
>> and
>> an HTML archive at the same time; sharing common media files or even
>> media
>> files in different formats. An application can save in its native format
>> for full-fidelity when the file is opened up in the same application
>> next
>> time, but also save in some more general format for wider distribution.
>> It
>> is not as if all the desktop applications won't support import and
>> export
>> of all the leading formats in a year's time, when the kerfuffle has died
>> down.
>>
>> Or an application can choose one format, but cherry pick data in other
>> formats as needed, if it is using a ZIP format that supports plurality.
>>
>> Is this a silly idea? Well, there are very successful precedents:
>> Apple's
>> fat binaries, mail in multi-part HTML and text, Open Type's packaging of
>> postscript and truetype fonts, and indeed the whole Internet stack with
>> its semi-loose coupling between layers.*
>>
>> In other words, the current fuss about choosing between brand A and
>> brand
>> B makes the fundamental mistake that either (or both) Brand A or Brand B
>> can be the end of the line and satisfy our needs. Now both ODF and Open
>> XML support various kinds of extensions, modularity and so on, but they
>> do
>> so from the POV of "how can we support this monolithic application?"
>> rather than from the POV of "how can we support pluralistic
>> applications?"
>>
>> What is needed is to take ZIP and work out what extra conventions are
>> needed to support this kind of plurality. OOXML's OPC goes much further
>> than ODF in this regard, but it is still not adequate. Then once a
>> proper
>> layering and modularity system is in place, to modularize ODF and OOXML
>> and XHTML etc to allow this kind of plurality.
>>
>> I have some more ideas on this on my blog  "Can a file be ODF and Open
>> XML
>> at the same time" if anyone is interested.
>> http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html
>> I thought the name .pax would be a good extension name, to give the
>> flavour.
>>
>> People who think that the evolution of file formats for "office" desktop
>> applications somehow ends in 2007 will naturally think of the current
>> ISO
>> process in terms of Brand A versus Brand B. It is a kind of panic
>> attack.
>> But I don't believe for a moment that it is the end of history: the real
>> game we need to be playing is how to put the ducks into line so that the
>> kind of pluralistic system becomes the natural win/win position for
>> vendors and users.
>>
>> Cheers
>> Rick Jelliffe
>>
>> * Now one area where this idea has not worked well has been the the
>> ability in HTTP MIME to specify alternative content types. However, as
>> with character set specification, I think this is because the MIME
>> header
>> level is the wrong place for this functionality: it needs to be a
>> fine-grain capability inside the resource and the resource-rendering
>> systems.
>>
>> What is the practical ramification on ISO standards? It means that we
>> need
>> to be moving towards much more fine-grained namespaces specific to
>> particular information units, and a refactoring of data to reduce the
>> amount of mixed namespaces in a file: for example, if a domain-specific
>> schema requires rich text in a field, that rich text should be in a
>> different resource to allow alternative implementations.
>>
>> That kind of route is the only way that I can see us ever getting to the
>> state where everyone can be happy: vendors can innovate and compete on
>> features, end users can have intereoperability, integrators have the
>> most
>> chance that the documents will include data in schemas they have already
>> coped with, expert users can have their requirements met without
>> overburdening lay users, value-adders can add their own niche-market
>> alternatives to the regular formats without breaking anything. Etc.  We
>> are getting really close to this, it is no a pipe dream or unrealistic;
>> the problem is how to get demand and support for this kind of .PAX
>> approach in a world where people are fixated by "OR" (my way or the
>> highway) rather than "AND" (I feel the urge to merge).
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>