XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] The year is 2027, and we need to examine archived XML documents from 2007 ...

Few?  Many? Some?

The problem is not standards, or open source, or propriety or XML.  It is
all of them.   Standards are seldom enough, propriety comes with enriched
features, and open source has support issues even with less features.   No
single example covers the span of claims made, but taken in total, the
increasing complexity of
documents-as-interactive-applications-comprised-of-multiple-components is
already passing the point of no return.  The are all short-lifecycle
applications and formats.  IOW, we are already having to translate, adjust
and inspect them frequently to keep them alive much less worrying about
2027.  XML helps to get some of the data out, but the costs of keeping these
apps online is going up fast.   In these bitter butter battles, we skip over
that point and keep hammering each other with the unsolved problems of
formats that are already past their sell-by-date.

I'm building HLS apps by day and real-time 3D by night.  At both ends of the
day, the problems of unequal implementations are tough.  The Europeans are
kicking Silicon Valley's bottoms in the real-time 3D market not by sales
tricks but by providing superior software.  Anyone sitting on their laurels
in California development or investment circles should grab for their
portfolios fast.  Even then, content that ran fine six months ago struggles
today on the SAME commercial non-open source platform.   The open source
alternatives are worse.  By orders of magnitude worse.  On the other hand,
the implementation that is working even with some format loss is orders of
magnitude better using the same standard from 1997.  Where it fails, it
fails because of dropping support for an older but still widely used
component format (gif animation in this case).

In other words, we can drop features, drop sizes of combinations, XML until
we are bloody, open source or close it, and we'll still not be able to play
these apps faithfully in 2027 without a sustaining active agency(ies) that
is archiving the software with the data.   As far as a change from 1989,
there is a great deal of data reach, but the churn still obsoletes the data.
If you want a better deal, you have to look past standards because they
can't fix this.  A combination of standards, contracts, participation
agreements and astute backups of software and possibly hardware are
required. 

IOW:  No change.

len

From: Jonathan Robie [mailto:jonathan.robie@redhat.com] 
 

OK, I'll bite. How can using open source with open, well-documented xml 
formats be a negative here? Few closed-source systems have done a very 
good job of providing open formats suitable for data archival. Some open 
source systems have.

In 2027, I will probably just want to extract the data as XML, but if I 
need more, nobody will have the versions of closed source software used 
to create data today. With closed source, they won't have access to the 
source code either. Of course, I'm all for well-supported software, and 
my company is very much in the software support business, but a support 
contract in 2007 doesn't ensure that you'll be able to read anything in 
2027.

Jonathan
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS