[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: PAX: Why OOXML and ODF are inadquate bases for a forwa

  • From: "Rick Jelliffe" <rjelliffe@a...>
  • To: "bryan rasmussen" <rasmussen.bryan@g...>
  • Date: Mon, 13 Aug 2007 21:18:47 +1000 (EST)

Re:  PAX: Why OOXML and ODF are inadquate bases for a     forwa
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@a...> 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@l...
>> subscribe: xml-dev-subscribe@l...
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>



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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.