Irrelevant, off-topic, but somehow funny ('those who ignore lisp are doomed...)":
This is from MS site: <uncle Bill says> "XAML" is the primary way to create a UI in the "Longhorn" programming model because it provides a way to separate UI definition from logic and enables you to integrate code within or behind markup. The ability to mix code with markup is important because XML does not support flow control well. </uncle Bill says>
The last sentence is interesting and mentions one of the key features that attracted me to Lisp: the ability to represent structured data (markup) and code at the same time with sexprs.
Unfortunately, MS isn't reinventing the wheel, they are reinventing the flat-tire (Mozilla's XUL).
"(...) XML does not support flow control well": That's precisely why it should be discarded, specialy when there's a better alternative available (sexprs). Sigh.....
> The last sentence is interesting and mentions one of the key features that > attracted me to Lisp: the ability to represent structured data (markup) and > code at the same time with sexprs.
Well, sexprs do not support flow control, CL does and it *uses* sexprs as the syntax of a lisp program, ie code and data.
after all what is (if (= a b) a b) as a sexpr? it becomes useful when you give some special value to the token 'if' when it is in the correct place in the sexpr.
> Unfortunately, MS isn't reinventing the wheel, they are reinventing the > flat-tire (Mozilla's XUL).
> "(...) XML does not support flow control well": That's precisely why it should > be discarded, specialy when there's a better alternative available (sexprs). > Sigh.....
Well XML does not support anything well, even XML.
> Well XML does not support anything well, even XML.
* Joe Marshall | Except, perhaps, the toner and paper industries.
Do not forget the memory and disk and bandwidth and Internet router vendors. Where would we /be/ today if he had software as storage- efficient as we had only 10 years ago? Take the Internet RFC index in XML, which has 65% XML and 35% contents. Back when I did standards, the telecom people designed things like ASN.1 with compact encodings so they would not waste any /bits/. Now watch me stumble and lie here on Memory Lane while the world rushes by.
-- Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
>>Well XML does not support anything well, even XML.
> * Joe Marshall > | Except, perhaps, the toner and paper industries.
> Do not forget the memory and disk and bandwidth and Internet router > vendors. Where would we /be/ today if he had software as storage- > efficient as we had only 10 years ago? Take the Internet RFC index in > XML, which has 65% XML and 35% contents. Back when I did standards, > the telecom people designed things like ASN.1 with compact encodings > so they would not waste any /bits/. Now watch me stumble and lie here > on Memory Lane while the world rushes by.
The more sensible XMLers (oddly a subset who also like lisp) are starting to use the mapping of XML schema/relaxng/DTD to ASN.1 spec and so define data that gets transmitted long hand to web browsers but as binary where bandwidth matters. We also sometimes wrap our XML parsers so they act as readers to our lisp interpreters, but everything ends up written in Java if we want to 'sell' it.
Erik Naggum wrote: > * Marc Spitzer >> Well XML does not support anything well, even XML.
> * Joe Marshall >> Except, perhaps, the toner and paper industries.
> Do not forget the memory and disk and bandwidth and Internet router > vendors. Where would we /be/ today if he had software as storage- > efficient as we had only 10 years ago? Take the Internet RFC index > in XML, which has 65% XML and 35% contents. Back when I did > standards, the telecom people designed things like ASN.1 with > compact encodings so they would not waste any /bits/. Now watch me > stumble and lie here on Memory Lane while the world rushes by.
I wasn't aware that XML ever pretended to be a binary standard. I admit my ignorance, but I thought it's supposed to be a "vaguely human-readable" text standard. You seem to be complaining that everything should be encoded in binary for efficiency purposes, dispensing with any other possible criterion.
> Erik Naggum wrote: >> * Marc Spitzer >>> Well XML does not support anything well, even XML.
>> * Joe Marshall >>> Except, perhaps, the toner and paper industries.
>> Do not forget the memory and disk and bandwidth and Internet router >> vendors. Where would we /be/ today if he had software as storage- >> efficient as we had only 10 years ago? Take the Internet RFC index >> in XML, which has 65% XML and 35% contents. Back when I did >> standards, the telecom people designed things like ASN.1 with >> compact encodings so they would not waste any /bits/. Now watch me >> stumble and lie here on Memory Lane while the world rushes by.
> I wasn't aware that XML ever pretended to be a binary standard. I admit my > ignorance, but I thought it's supposed to be a "vaguely human-readable" text > standard. You seem to be complaining that everything should be encoded in > binary for efficiency purposes, dispensing with any other possible > criterion.
"Brandon J. Van Every" <try_vanevery_at_mycompanyn...@yahoo.com> writes:
> Erik Naggum wrote: > > Do not forget the memory and disk and bandwidth and Internet router > > vendors. Where would we /be/ today if he had software as storage- > > efficient as we had only 10 years ago? Take the Internet RFC index > > in XML, which has 65% XML and 35% contents. Back when I did > > standards, the telecom people designed things like ASN.1 with > > compact encodings so they would not waste any /bits/. Now watch me > > stumble and lie here on Memory Lane while the world rushes by.
> I wasn't aware that XML ever pretended to be a binary standard. I admit my > ignorance, but I thought it's supposed to be a "vaguely human-readable" text > standard. You seem to be complaining that everything should be encoded in > binary for efficiency purposes, dispensing with any other possible > criterion.
Surely not everything, but seeing tools that are explicitly designed to hide the "human-readable" format from any human's view makes you wonder... Debugging auto-generated SOAP messages is not in any way more fun than it would be with a binary protocol.
> "Brandon J. Van Every" <try_vanevery_at_mycompanyn...@yahoo.com> writes:
> > Erik Naggum wrote: > >> * Marc Spitzer > >>> Well XML does not support anything well, even XML.
> >> * Joe Marshall > >>> Except, perhaps, the toner and paper industries.
> >> Do not forget the memory and disk and bandwidth and Internet router > >> vendors. Where would we /be/ today if he had software as storage- > >> efficient as we had only 10 years ago? Take the Internet RFC index > >> in XML, which has 65% XML and 35% contents. Back when I did > >> standards, the telecom people designed things like ASN.1 with > >> compact encodings so they would not waste any /bits/. Now watch me > >> stumble and lie here on Memory Lane while the world rushes by.
> > I wasn't aware that XML ever pretended to be a binary standard. I admit my > > ignorance, but I thought it's supposed to be a "vaguely human-readable" text > > standard. You seem to be complaining that everything should be encoded in > > binary for efficiency purposes, dispensing with any other possible > > criterion.
http://www.tilton-technology.com/ --------------------------------------------------------------- "[If anyone really has healing powers,] I would like to call them about my knees." -- Tenzin Gyatso, the Fourteenth Dalai Lama
> Irrelevant, off-topic, but somehow funny ('those who ignore lisp are > doomed...)":
Eh. Microsoft is reinventing Lisp all over the place, and mostly doing a poor job of it. C# 2.0 will have real closures and lambda (yay!) but doesn't generalize iterators and enumerators on top of them (boo!). Project Xen (the language formerly known as X#) will bring support for some domain specific languages (SQL and XML) into C#, but they won't provide a general framework (macros) for adding support for custom ones. And oblivious to Lisp-family compiler technology, they retain the struct/class distinction...
In one way it might be a good thing, since more people are exposed to these powerful ideas, but its painful to see them being done so hackishly...
* Brandon J. Van Every | I wasn't aware that XML ever pretended to be a binary standard.
Good, because nobody said anything to that effect.
| I admit my ignorance, but I thought it's supposed to be a "vaguely | human-readable" text standard. You seem to be complaining that | everything should be encoded in binary for efficiency purposes, | dispensing with any other possible criterion.
I do no such thing. Please learn to accept responsibility for your interpretation of what other people write and try to do a better job of reading what people actually write. Please become aware of your preconceptions and unlearn your resemblace-based reasoning habits. Just because something looks like something you know, does not mean that it is what you already know. You need to be aware of differences from what you already expect in order to avoid pissing people off by pretending that they said what you object to.
-- Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
-- * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/> - Debating gives most of us much more psychological satisfaction than thinking does: but it deprives us of whatever chance there is of getting closer to the truth. -- C.P. Snow
Erik Naggum wrote: > Do not forget the memory and disk and bandwidth and Internet router > vendors. Where would we /be/ today if he had software as storage- > efficient as we had only 10 years ago? Take the Internet RFC index in > XML, which has 65% XML and 35% contents. Back when I did standards, > the telecom people designed things like ASN.1 with compact encodings > so they would not waste any /bits/. Now watch me stumble and lie here > on Memory Lane while the world rushes by.
Agreed on XML. It certainly is verbose. But I get shivers up my spine when anybody mentions ASN.1. That is NOT the way to go. (Memories of various ATM signalling specs and everything coming from ITU -- yuck!) ASN.1: bandwidth efficient? Yes, generally so. Speed efficient? Not at all. Way too much packing and unpacking to save a bit here or there. Personally, I vote for things like Sun's old XDR (search Google for the RFC, it's used in NFS and they standardized it in an RFC as a result). Not as comprehensive as ASN.1 in the whole data model and not quite as space efficient, but far more efficient in space than XML and oodles faster than ASN.1. XDR assumes a 32-bit machine and aligns pretty much everything to a 32-bit boundary. Even with endian swapping on an Intel machine (XDR is big-endian), it rocks. Even that can be solved with the types of wire encodings used by DCE RPC and CORBA.
* Dave Roberts | Agreed on XML. It certainly is verbose. But I get shivers up my spine | when anybody mentions ASN.1. That is NOT the way to go.
This generally depends on the encoding rules. There are many of them. Only some of them are CPU-intensive. Some of the problem is that ASN.1 is not a precise match for the programming language's internal data structures. Environments that make a better fit between ASN.1 and the data structures of the programming language suffer much less than those that insist on using only «native» data structures.
Just for kicks, I did a search for «XML» at groups.google.com to see its incidence rate and tabulated the results per month. One has to search for many much shorter intervals, or the number of matches becomes a useless constant, so in case anyone else wants to know, the data and the simple figure are available here:
+ Friedrich Dominicus <fr...@q-software-solutions.com>:
| Marc Spitzer <mspit...@optonline.net> writes: | | > Harald Hanche-Olsen <han...@math.ntnu.no> writes: | > | >> + Kenny Tilton <ktil...@nyc.rr.com>: | >> | >> | <hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bi t><bit>1</bit><bit>0</bit></hex> | >> | >> See also RFC 3252. | > | > And I thought I was making a bad joke. | You did have seen it's name "BLOAT" and the date of publication?
The 1 April RFCs are a great tradition. My personal favourite is still RFC 1149, Standard for the transmission of IP datagrams on avian carriers [i.e., carrier pigeons]. (And its follow-up RFC 2549, IP over Avian Carriers with Quality of Service.)
Avian carriers can provide high delay, low throughput, and low altitude service.
-- * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/> - Debating gives most of us much more psychological satisfaction than thinking does: but it deprives us of whatever chance there is of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <han...@math.ntnu.no> wrote: +--------------- | <hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bi t><bit>1</bit><bit>0</bit></hex> | | See also RFC 3252. +---------------
But note that RFC 3252 suggests (requires? -- I can't tell for sure) that bitmasks be converted into "human-readable values", so the above might be more properly represented as:
or if one's DTD allows <hex> attributes to default to "0", then just:
<hex bit5="1" bit3="1" bit1="1"/>
But best, of course, would be if the bits' actual semantic meanings were displayed, e.g, as in the <tos> and <flags> elements in the example IP packet in Section 2.2:
Dave Roberts wrote: > Agreed on XML. It certainly is verbose. But I get shivers up my spine when > anybody mentions ASN.1. That is NOT the way to go. (Memories of various ATM > signalling specs and everything coming from ITU -- yuck!) ASN.1: bandwidth > efficient? Yes, generally so. Speed efficient? Not at all. Way too much > packing and unpacking to save a bit here or there.
ASN.1's grammar is butt-ugly.
As for efficiency of using ASN.1 specifications -- doesn't this depend on the encoding rules you've chosen? The packed encoding rules do require a lot of bit twiddling, but presumably you use that when the bandwidth really is tight (like, say, in wireless protocols.)
BTW, there are now XML encoding rules for ASN.1. :)
Paul F. Dietz wrote: > ASN.1's grammar is butt-ugly.
Yes, agreed.
> As for efficiency of using ASN.1 specifications -- doesn't this depend on > the encoding rules you've chosen? The packed encoding rules do require > a lot of bit twiddling, but presumably you use that when the bandwidth > really is tight (like, say, in wireless protocols.)
Yes, it does. I'm assuming BER here. PER is even better for space, but again suffers for speed of encoding/decoding. You can, of course, encode ASN.1 in something that is totally inefficient, if you want. It just isn't typically done that way. I guess that's your point, though--it's really an encoding issue, not a specific ASN.1 issue.
> BTW, there are now XML encoding rules for ASN.1. :)
Yes. The general stupidity of people continues to amaze me... ;-)
Ray Dillinger <b...@sonic.net> writes: > Marc Spitzer wrote:
> > let me clarify, I looked at the rfc but forgot to check the date.
> > But my favorite rfc of all time is the rubber chicken rfc.
(Which one's that?)
> My favorite specified a network protocol for transmitting sheep over SONET.
Personally, I'm a fan of the Infinite Monkey Control Protocol Suite, but then I like monkey jokes. Maybe I'll work on an implementation, cl-monkies ;-)
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
