OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] SAX for Binary Encodings (SAD-SAX)

[ Lists Home | Date Index | Thread Index ]

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@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA




 

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

Copyright 2001 XML.org. This site is hosted by OASIS