Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Where does the "nothing left but toolkits" myth come f
 > -----Original Message----- > From: Elliotte Harold [mailto:elharo@m...] > > Rich Salz wrote: > > Let's ignore the Infoset. But if we posit > > XML --> a binary serialization --> XML > > > > how does that atively damage the XML community? > > First, you have to realize that most binary proposals to not in fact > posit that. They either superset or subset or only intersect with > regular XML. But if we rule all those formats out, there are still > problems: > > 1. Patents are beginning to invade this space, closing off > interoperability and open software. All the more reason to create a decent standard before the space is completely closed off, baring entry of useful, innovative ideas. Easiest way to block a patent is to publish the same idea openly first. > 2. The data that's transmitted in this binary format is less inspectable > than data in the regular XML format. True. In my actual experience with binary-xml, this is possibly the single largest weakness. Then again, by tying binary-xml to XML, you gain the significantly improved possibility of being able to alternatively send the data as text-xml. A critical component of any binary-xml design should be to emphasize that binary-xml is just an optimization of the normal text-xml path. This is a key reason why I think binary-_X_M_L_ is actually better than ASN.1 or some new format. > 3. Software vendors will publish tools that only consume the binary > data; and therefore systems will refuse to accept the textual data. Just as today there are vendors who only consume ASCII or UTF-8 XML. This relates back to 2, and to general market pressures. If the market really only wants binary-xml, then let it go. I tend to believe that most markets will quickly see the value in being able to choose text or binary, depending on the current needs. Are you debugging, or still building the system? You probably want text-xml (back to your point #2). Are you focused on tuning your system for absolute throughput, choose binary. > 4. Binary parsers often forgo well-formedness checks such as name > characters that textual parsers make. They incorrectly assume that > nobody can or will inject broken data into the system. I am in complete agreement with you here as well, but this can be addressed (and should be) by conformance tests, and clear requirements within the specification. > These problems are not insurmountable, but once you surmount them you're > very close to reinventing real XML, and being about as fast and maybe > marginally slower. Reinventing XML would mean going back to SGML and restarting the long and arduous process of trimming that down. Binary-xml is not about reinventing XML, it is about leveraging large parts of the existing XML ecosystem of tools, languages, and general knowledge. Having worked with binary-xml, in a number of forms, including implementing full well-formedness validation, binary-xml can easily be much faster than XML. For some scenarios (especially where binary serialization would avoid numeric type conversions) the performance gain can be huge. Basically, you appear to be arguing that existing proposals are flawed; therefore all future proposals will be similarly flawed. That logic would have prevented XML from ever happening, would mean that hybrid cars would never exist, etc. I'm not sure that W3C can succeed with their binary-xml effort, but declaring it broken provides value to no one. -derek 
|
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
|
|||||||||
