[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Rick Marshall [mailto:rjm@zenucom.com]
> Sent: Tuesday, August 05, 2003 17:59
> To: Bullard, Claude L (Len)
> Cc: 'Rex Brooks'; 'Robin Berjon'; 'Liam Quin'; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Patented XML Compression Techniques
> (WAS RE: [xml-dev] Binary XML == "spawn of the devil" ?)
>
>
> just for the record len, seeing as we've spent a lot of time
> on this....
>
> redhat is now suing sco, essentially for mischief, for
> claiming ip when none exists
>
> so ip can protect what you've done, it can also, it is
> alleged, be used as a threat and to manipulate the market
>
> imho the w3c needs to be very careful about this binary business
>
> i'd rather see the rdbms model where the external view (rows)
> and the access method or api (sql) are are ascii and in the
> case of sql - a standard; while the storage of data -
> possibly binary, and the optimisers that go with it are as
> proprietary as you like with all the ip and other stuff that suits
>
> the important principle being that the data access and
> interchange are not ip owned by any one company or individual
>
> xml really should stay the same - the formats are public and
> specified. if a company wants to develop and market a system
> for high speed transfer of xml data between systems - good
> luck. if they want to release a high speed xslt processor -
> good luck. if you want to offer a publicly available service
> - then stick to the ascii, xml 1.0 and friends.
>
> fwiw i think standardisation in this area will only limit
> innovation and increase the costs of participation for
> smaller companies and individuals
A couple of weeks ago I mentioned the new standard initiative that has been
started as joint work of JTC1 and ITU-T, regarding both a schema-independent
representation of the XML infoset using ASN.1 and PER, and a semantic
equivalent of the SOAP 1.2 envelope defined in ASN.1.
The standard will also specify:
- how datatypes defined in ASN.1 and encoded in PER (or any other standard
encoding rules of ASN.1) can be exchanged by including them in an ASN.1-SOAP
envelope
- how to include in an ASN.1-SOAP envelope an infoset for which a schema has
not been provided, by representing it in ASN.1 and encoding it in PER
- how to handle data definitions specified in XML Schema: the schemas will
be translated to ASN.1 using the X.694 standard mapping
- how to handle canonicalization issues when using binary encodings
- content negotiation issues
and so on.
Note that:
- the ASN.1 language standards are open and freely downloadable from the
ITU-T website
- there is no IP encumbrance on the ASN.1 language standards, and there will
be none on the new prospective standard mentioned above
- the new prospective standard satisfies your requirement that the data
access and interchange are not IP owned by any one company or individual
- the new prospective standard satisfies your requirement that the formats
are public and specified
- there is no reason that standardization in this area will increase the
costs of participation for smaller companies and individual. Several ASN.1
langage tools are freely available. A service based on the ASN.1-SOAP
envelope, application data types defined in ASN.1, and the ASN.1 schema for
the infoset, can be implemented using either free tools or professional
tools.
Alessandro Triglia
OSS Nokalva
>
> rick
>
> On Wed, 2003-08-06 at 00:39, Bullard, Claude L (Len) wrote:
> > Not quite.
> >
> > http://octaga.com
> >
> > Sometimes the patented and open technolgies play well
> > together and the licensing is paid for by the vendor.
> > The end user gets the player for free, but the editor+codec
> > may cost and again, the cost of licensing is bundled
> > into that. That is how gif was handled. This stuff
> > is a problem for open source groups, admittedly, so
> > it is better to seek alternatives to licensing. The
> > only thing one cannot do is ignore the patents because
> > we are back to the indemnity problem. It is better
> > to convince the patent holder that the market opportunities
> > are better if open source is enabled. That is a
> > sales job and not always an easy one.
> >
> > I am not concerned that firms patent IP as long as they
> > play by the rules of the standards and specifications
> > organizations when they make a submission, and hide
> > no details that taint the products. XML binarization
> > is an area in which patents exist. Ok. As long as
> > submissions to the W3C or others fit within the policies,
> > no problem. It will be a problem if the only acceptable
> > solution is one that they will not submit under those
> > policies. Then the organizations have to standardize
> > an inferior technology or pay the tolls. Fortunately,
> > there aren't many technologies for which acceptable
> > alternatives aren't available, or that is the position
> > some take.
> >
> > What one must have is a level playing field before
> > the law.
> >
> > len
> >
> >
> > From: Rex Brooks [mailto:rexb@starbourne.com]
> >
> > Somebody stick a fork in MPEG. It's done. In fact its way
> overcooked.
> > Like a dinosaur brain that hasn't yet got the message that its dead
> > yet. --courtesy dept of redundancy dept. Better yet,
> require it carry
> > a poison warning symbol.
> >
> > Taps, please,
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
