[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
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|