Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX for Binary Encodings (SAD-SAX)
 Elliotte Rusty Harold wrote: >> 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. Yes there is - that's what I'm suggesting; that the application tells the parser its intentions by supplying it with some kind of schema. >> 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. You're confusing the issues here, that's not what I'm talking about. >> 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? XHTML assigns 'integer' semantics to width and height attributes all over the place. And 'url' semantics to various src and href attributes. Yes, you could indeed write <img src="..." width="three inches"> within the XHTML namespace and save it to disk, and humans who read that would be able to make sense of it. But an XHTML processing application isn't required to make sense of it. The XHTML spec assigns a type to that width attribute, and that type states that it has to be an integer, and indeed a particular representation of an integer (decimal). This is good for interoperability - if there was no such type constraint, then some XHTML browser authors might think "Hmmm, a width attribute... since my target market for this XHTML parser is really people writing XHTML and they're all design consultants who are more familiar with printed brochures than computers, so I'll parse it as English text with the name of a unit of measurement in". While some may say "Hmmm, I'll take this attribute as a decimal number containing a number of pixels, because that's easy". And lo! No XHTML document containing width attributes will then work on both at the same time. The type constraints in *valid* XHTML documents exist to place a bound on the work required in an imlementation. The implementator knows he can call his XHTML browser 'complete' when it handles integers in the width element - complete in the sense that it will be able to correctly render valid XHTML. But he is not prevented from thinking "Eh, people are stupid; I bet somebody will write an XHTML document with an invalid width attribute... I've got some spare time, I think I'll make my browser support a few extra possible ways of expressing a width, just so that my browser will display some documents others won't". If he really really really wants to. > I think you're very confused. You don't get the difference > between local interpretation of an XML document and the document itself. Yes I do; all I'm talking about here is a local processing API. > 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. As I mentioned in the other reply, though, it's no change to SAX APIs to add an optional SAX extension. > 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. Hmmm? [Alaric thinks] Ah, I see. The original point was that people *were* writing SAX interfaces to ASN.1 encodings like BER and PER, just that one consequence of this was that the parsers were reading in an integer and converting it to a string to pass into the characters callback, which seems wasteful when the application goes straight ahead and parses it back to an integer. That doesn't mean that SAX *needs to change* to match ASN.1, now, does it? Because you clearly *can* just convert everything to text and feed it to the application like that. It's just that allowing the application to say "Psst, SAX event source, I'm interested in native values - pass me some when you can" will enable the SAX parser - if it wants to - to save some time. > 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. Doesn't work so well for raster image formats, file system structures, or data compression formats, though, does it? :-) >> 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. It doesn't change either SAX or XML, though. > Bottom line: I think the people clamoring to force binary data into our > nice clean text environment have an inferiority complex. I can't say I've met any, so I wouldn't know. > I don't think > you actually believe your binary data and formats can survive on their > own merits. Computers processed numbers before they processed text; right now we're seeing if *text* can survive on its own merits. Because it hasn't yet ousted binary... > 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. Why would we waste the effort? What would be our motiviation to push a model we know is inferior? Wouldn't the effort be better spent > 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. Binary formats and APIs for handling them already exist, and did so long before XML came around. They're already pretty successful; you use them whenever you pick up the phone, use a computer, look at your wristwatch, watch TV, drive a recently made car, pay tax, interact with your bank, etc. They don't seem to be dying off now XML is around, either. What more can I do to prove you wrong than that? ABS 
|
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
|
|||||||||
