Java’s Future Lies In Mobile?

[Arne Vajhøj]

A very free form

It can actually be pretty well defined via schemas.

BTW, you have not played with XSLT yet?



Arne

 

[Arne Vajhøj]

It's probably a neat idea, but I am not used to xml [sic]

It is a little strange to lay out graphics with XML - it's like drawing
a picture with words. But no Java programmer can afford to be unfamiliar
with XML.

Seems to be the standard for information exchange.
Hopefully the last such.

There is every reason to believe XML will be
widely used for at least 10-20 years more, because
almost everybody is pushing it - Java, .NET etc..

Arne

 

[Eric Sosman]

Dirk Bruere at NeoPax wrote:
It's probably a neat idea, but I am not used to xml [sic]

It is a little strange to lay out graphics with XML - it's like drawing
a picture with words. But no Java programmer can afford to be unfamiliar
with XML.

Seems to be the standard for information exchange.
Hopefully the last such.

There is every reason to believe XML will be
widely used for at least 10-20 years more, because
almost everybody is pushing it - Java, .NET etc..

XML will still be used in 10-20 years for all the same
reasons COBOL will be.

Unfortunately, all of today's DTD's will have been mislaid
or forgotten, so the XML you write today will be unintelligible.

0.5

 

[Lew]

Just by:
* use default namespace
* remove indentation
* use short names
* prefer attributes over elements
the readability of an XML document can be somewhat reduced.

The first three of these are not really needed if you ZIP the XML for
transfer. In my experience the processing time for the content is more
significant than the length of the identifiers once the XML is at its
processing station, but I'm swayable by evidence. You've alluded to evidence,
you are a credible source, so I now know that these techniques have increased
performance.

Which performance?

Better than other ways, e.g., ZIP, that reduce the impact?

As for the fourth, that definitely reduces readability, as you say, but how
does it improve performance?

 

[Dirk Bruere at NeoPax]

It can actually be pretty well defined via schemas.

BTW, you have not played with XSLT yet?

No!
I'm waiting for polymorphism in the next issue...

 

[Dirk Bruere at NeoPax]

That is not my experience.

Most XML (the exception typical being design by committee format)
seems rather readable to me.

start element with name for what it is + attributes with
additional information + data + end element

seems pretty logical to me.

It is also very similar to structured control structues
in programming languages.

Arne

And displaying it in color helps

 

[Dirk Bruere at NeoPax]

What, nobody asked “is that binary or decimal�

Geeks aren’t what they used to be...

The world would have been a better place if we had 12 fingers instead of 10

 

[Dirk Bruere at NeoPax]

On 10/03/2011 23:08, Lew wrote:
Dirk Bruere at NeoPax wrote:
It's probably a neat idea, but I am not used to xml [sic]

It is a little strange to lay out graphics with XML - it's like drawing
a picture with words. But no Java programmer can afford to be
unfamiliar
with XML.

Seems to be the standard for information exchange.
Hopefully the last such.

There is every reason to believe XML will be
widely used for at least 10-20 years more, because
almost everybody is pushing it - Java, .NET etc..

XML will still be used in 10-20 years for all the same
reasons COBOL will be.

Unfortunately, all of today's DTD's will have been mislaid
or forgotten, so the XML you write today will be unintelligible.

0.5

And let's not mention video compression standards...

 

[Lew]

No!
I'm waiting for polymorphism in the next issue...

I don't get it.

 

[Lew]

And displaying it in color helps

Depends on the color scheme.

 

[Lew]

The world would have been a better place if we had 12 fingers instead of 10

Nonsense. In medieval times people used base 12 and they had 10 fingers. the
Babylonians used base 60 and they had 10 fingers. There's no necessary
connection between fingers and bases.

I can count to 1023 (decimal) on my fingers. I have ten fingers also.

I prefer to limit the range to 0-255 partly for cultural reasons and partly to
gain condition/check and overflow/carry digits.

You could make a video of a computer using a pair of hands for each byte.
That'd be a video of a 1001 extras.

You'd have to hit up the bridge clubs and golf courses to find foursomes for
32-bit computing (plus eight spare digits per word).

Maybe we could combine all those spare digits to create a low-capacity thumb
drive.

 

[Joshua Cranmer]

The first three of these are not really needed if you ZIP the XML for
transfer. In my experience the processing time for the content is more
significant than the length of the identifiers once the XML is at its
processing station, but I'm swayable by evidence. You've alluded to
evidence, you are a credible source, so I now know that these techniques
have increased performance.

Which performance?

Pretty-printed verbose XML is larger than the tightest, most illegible
XML by a factor of 5, if not larger; even the tightest XML is larger
than a well-designed binary format by around a factor of 5-10. You can
store time within second precision in 4 bytes in binary, but the same
value (without delimiters) is 15 bytes in plain text and 20 bytes in a
more readable format. And then you have to waste space on the XML
structure information which is implied by the binary format.

 

[Lew]

Pretty-printed verbose XML is larger than the tightest, most illegible XML by
a factor of 5, if not larger; even the tightest XML is larger than a
well-designed binary format by around a factor of 5-10. You can store time
within second precision in 4 bytes in binary, but the same value (without
delimiters) is 15 bytes in plain text and 20 bytes in a more readable format.
And then you have to waste space on the XML structure information which is
implied by the binary format.

So?

I was asking about performance, not size. As mentioned, ZIP handles the
performance implications of the size just fine. So that's a red herring.

And "waste" is a pejorative - it's only a "waste" if you don't get back the
cost in benefit. Just like a "weed" is only a plant for which you don't know
the use.

 

[Mike Schilling]

So?

I was asking about performance, not size. As mentioned, ZIP handles the
performance implications of the size just fine.

The communications implications of size. It increases CPU usage, since it
adds the need to zip and unzip the message, and doesn’t affect the memory
usage, since after unzipping it's the same size as before. XML is also
fairly expensive to parse, and not that cheap to produce, largely because of
the need to check each string for characters that need to be escaped. .

The most efficient way to handle XML that I know of is Fastinofset. No
escaping, no character-by-character parsing, nothing as cpu-intensive as zip
or unzip, and roughly the same amount of compression.

 

[Dirk Bruere at NeoPax]

I don't get it.

I always get the term mixed up with multiple inheritance - a weird dyslexia.
So, two XSLT documents, one on QM and the other on GTR.
The result is a TOE and I get my Nobel Prize

 

[Dirk Bruere at NeoPax]

Depends on the color scheme.

Yeah - white on white is a bit of a pain

 

[Dirk Bruere at NeoPax]

In some cases it can have a significant effect.


Except in those cases where it has an important benefit.


You may think it is negligible.

But in some cases it has been measured to be important.

Arne

Processing power and bandwidth are only going to get cheaper for the
next 30 years

 

[Arne Vajhøj]

On 10/03/2011 23:08, Lew wrote:
Dirk Bruere at NeoPax wrote:
It's probably a neat idea, but I am not used to xml [sic]

It is a little strange to lay out graphics with XML - it's like drawing
a picture with words. But no Java programmer can afford to be
unfamiliar
with XML.

Seems to be the standard for information exchange.
Hopefully the last such.

There is every reason to believe XML will be
widely used for at least 10-20 years more, because
almost everybody is pushing it - Java, .NET etc..

XML will still be used in 10-20 years for all the same
reasons COBOL will be.

True.

But unlike for COBOL the replacement is not ready yet.

Arne

 

[Arne Vajhøj]

Processing power and bandwidth are only going to get cheaper for the
next 30 years

Yes.

And as a consequence the number of cases where nice XML is
not fast enough will shrink (and it is not even at a high
level today).

Arne

 

[Arne Vajhøj]

The first three of these are not really needed if you ZIP the XML for
transfer. In my experience the processing time for the content is more
significant than the length of the identifiers once the XML is at its
processing station, but I'm swayable by evidence. You've alluded to
evidence, you are a credible source, so I now know that these techniques
have increased performance.

Which performance?

Better than other ways, e.g., ZIP, that reduce the impact?

As for the fourth, that definitely reduces readability, as you say, but
how does it improve performance?

Compression only reduces the transfer size (and most likely the
transfer time), but it does not reduce parsing time.

All the above reduces size of the uncompressed XML. And that reduces
the parsing time.

Fewer characters to read, shorter names to compare, larger part of
data in faster storage.

The fourth works the same way x="123" is shorter than <x>123</x>
and with a SAX parser (which would be the obvious choice where
this discussion is relevant), then the attribute approach gives
a lot simpler code.

All this obviously only have relevance if:
* there is a lot of XML to be parsed (like huge XML file)
* parsing is relative expensive compared to the processing
of data (like only a tiny part of the data is actually
being used)

This is not the standard case. This is 1 out of a 1000 cases.

My point is that such cases can exist.

In 999 out of a 1000 cases these techniques is a prime
example of how bad premature optimization, micro optimization
etc. can be.

Arne