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

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

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
>
>