[
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
|
