[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX for Binary Encodings (SAD-SAX)
At 12:34 AM +0000 11/9/03, Alaric B Snell wrote: >"This won't work." You say. So if somebody produced working code >that did this would you eat humble pie? I'm sure you can make an ugly hack, but I defy you to come up with a clean, legible, robust solution. >1. ((Integer)value).intValue (). A slightly ungainly expression, >yes, but bear in mind that the next version of Java, IIRC, will have >automatic conversion between primitive values and their 'boxed' >forms. Ungainly, ugly, error-prone and worse than what we have now. And I don;t think even Java 1.5 is going to remove the need for the cast. >And anyway, that's just a wrinkle in Java's type system. The C >version of the API would probably pass in a discriminated union of >int, long, etc, from which you would indeed pull out the primitive >value. Good for C, but SAX has long been explicit in being a *Java* API that makes no compromises to fit other languages. Just as no one API will fit all formats, no one API will fit all languages. (DOM's living proof of what horrors you get when that's tried.) An event based push API for C should use C's conventions, not Java's. >And you're saying that passing in objects when people want primitive >values is bad - but you condone passing in a CHARACTER STRING when >people want primitive values? So they have to parse it rather than >just unboxing it?!?! I'm saying pass in what the parser actually knows: the text. The parser knows nothing else. The local application may know more, and thus it is the right place to do the conversion, but an XML parser knows nothing more than the text. There is no way for the parser to know in advance how an application is going to want to interpret any given piece of text. If the application chooses to treat 010 and 10 as the same or different, that's it's business. The parser doesn't know what the application is going to want to do, and should not be making the decision for it. >2. "It's type unsafe", crows the guy who wants to interchange all >information typelessly as strings! Hahaha! That made my day. You're confusing data and code. Strong types help the code (well, to be honest, I'm not 100% convinced of that any more, but it is the Java way and code written without types in Java is ugly and error prone. A true dynamically typed language like Python is a different story. But we're talking about SAXX and therefore Java.) However, types do not extend usefully beyond the local program. My types are not your types, and don't have to be. >But a plain-and-simple-XML-1.0 application would still be able to >quite happily just have its characters() callback invoked for every >bit of CDATA and in the document, and just ignore all of this stuff, >quite happily. Nothing there would need to change. Not if what's in the stream is binary data instead of text. If I see the bytes in the stream representing the number 10.5. I don't know whether the text is really 10.5 or 10.500. The difference is significant in some contexts. >Nothing would be polluted! >Now look, I don't really think you're stupid; my snotty tone in this >and the last email is just because I really don't think you're being >a useful contributor to this discussion, and that annoys me... >you're just saying "No, it'll never work, because some people use >XML in a way that won't need this stuff. I see XML as just text, so >everyone else must too". Lots of people are already using XML in >not-just-text ways. Really, Who? I think you're very confused. You don't get the difference between local interpretation of an XML document and the document itself. The document is text. That's all. > This hasn't broken plain old XML yet; you can ignore all the >schemas and everything and pass text with pointy brackets around to >your heart's content. Nobody will stop you; nobody wants to stop >you. If you're not interested in typed information, then treat it as >you would treat a discussion on any other topic that's not relevant >to you - ignore it. If you are interested, then can you do better >than sitting there saying "That's not how I want to use XML. So you >can't either!"... I have no objection if you want to define your own binary formats and APIs for processing them. I object greatly when you try to pollute the very useful XML and SAX APIs with things they were never intended to handle. If you can use XML and SAX as you claim, go ahead, But you're saying you can't. You're saying you need to change them; that they aren't good enough as is. I think that just proves my point that XML and SAX aren't about binary data. They're about text. And I want them to remain about text, because text works. >We are not your enemies! We're just engineers and scientists, trying >to improve the technological state of the art for the betterment of >humanity, yes? :-) You may believe that, but it isn't true. What's being proposed here is actively harmful to the technological state of the art. It would make SAX worse, not better. It would make XML much worse, not better. Bottom line: I think the people clamoring to force binary data into our nice clean text environment have an inferiority complex. I don't think you actually believe your binary data and formats can survive on their own merits. I think you know the ASN.1 dog won't hunt, and if you run it up the flagpole nobody will salute. I think that's why you're fighting so hard to force SAX and XML to contort to fit your needs. I think you believe that if you defined your own binary, typed APIs and formats, they would not be adopted because they'd be recognized as inferior to XML. And I claim you think that the only way to get your binary, typed formats and APIs adopted is by attaching the XML brand to them. Disagree with me? Then prove me wrong. Create binary formats and APIs for handling them without polluting XML. I won't stand in your way. If you're successful, that's a win for everyone. But I don't believe you can, and I'm really afraid you're going cripple or destroy XML and SAX because you know you can't win otherwise. -- Elliotte Rusty Harold elharo@m... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
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
|