quote: Original post by Themonkster
XML provides a way for 2 different business's to exchange data with out knowing the in's and out's of the others system or file format.

Bullshit.

quote:
I can't see any other soloution out there that has the same flexiablity as XML.

Symbolic expressions are *more* flexible.

[edited by - SabreMan on February 12, 2003 4:45:25 AM]

quote: Bullshit.

See, now that''s not constructive at all ... he said it provides A way, not THE way.

quote: Symbolic expressions are *more* flexible.

I''m not trying to argue here ... but please, give an example of how this method if *more* flexible. I honestly want to learn, as I believe that only with a good knowledge of alternatives can you truly master a discipline.

Joel Martinez
http://www.codecube.net/

quote: Original post by joelmartinez
See, now that''s not constructive at all ... he said it provides A way, not THE way.

It doesn''t provide a way of interchanging data without knowing anything about the system you are talking to or the file format it expects. It would be just as ridiculous to suggest that XML allows you to perform magic.

quote:
I''m not trying to argue here ... but please, give an example of how this method if *more* flexible.

Read this and this.

And how in the name of crap is

#1=(a b #*0111(d e #1#) #c(2 3/2))

easier to understand/parse on any and every platform??

Of course it''s impossible to exchange data with another system without the developer knowing the details of the other system ... there''s no way around that. However, when faced with the choice of XML, or a comma delimited file (along with accompanying document to explain what each "field" stands for) ... I would much rather have XML where I can just look in the file myself and see what fields are available.

There''s always gonna be bad examples of XML ... and sure it''s not suited for everything ... and sure it can be a little bloated for some applications. But in the right circumstance (such as exchanging data with an insurance carrier, or storing application settings, or storing game map data) ... it can work wonders over the alternative.



Joel Martinez
http://www.codecube.net/

quote: Original post by joelmartinez
And how in the name of crap is

#1=(a b #*0111(d e #1#) #c(2 3/2))

easier to understand/parse on any and every platform??

We need to see the XML equivalent before that can be answered. But yes, the tools to parse it are already available on most platforms.

quote:
Of course it''s impossible to exchange data with another system without the developer knowing the details of the other system ... there''s no way around that.

Right. So a claim that it is possible is bullshit.

quote:
However, when faced with the choice of XML, or a comma delimited file (along with accompanying document to explain what each "field" stands for) ... I would much rather have XML where I can just look in the file myself and see what fields are available.

Have you just read the entirety of two long Usenet posts regarding symbolic expressions only to come back and whitter on about CSVs? CSVs have got nothing to do with s-expressions, and I''ve never mentioned CSVs. What are you on about? Did you actually read the posts beyond the example you''ve quoted?

quote:
There''s always gonna be bad examples of XML ... and sure it''s not suited for everything ... and sure it can be a little bloated for some applications. But in the right circumstance (such as exchanging data with an insurance carrier, or storing application settings, or storing game map data) ... it can work wonders over the alternative.

The alternative being what?

quote: We need to see the XML equivalent before that can be answered. But yes, the tools to parse it are already available on most platforms.

And that right there is part of the appeal of XML ... Even if I had never seen the spec for a document I was looking at (as with this), I''d be able to figure it out just by looking at it and work it into my app.

quote: Have you just read the entirety of two long Usenet posts regarding symbolic expressions only to come back and whitter on about CSVs? CSVs have got nothing to do with s-expressions, and I''ve never mentioned CSVs. What are you on about? Did you actually read the posts beyond the example you''ve quoted?

I think we''re both starting to talk about totally different things here. To me, XML is simply a means of storing information ... not using it as a scripting language, or anything else as you seem to be implying (or the posts for that matter).

quote: The alternative being what?

Perfect example is SVG. What better way to store vector graphics than XML. This way, the file can be read and modified very easily by any application without having to know some obscure binary file format. And before you say it, no it''s not a replacement for gif or jpg files, and yes I realize that storing it with XML will take up more space ... but that''s something I''m willing to deal with given the benefits of working with SVG.

Joel Martinez
http://www.codecube.net/

quote: Original post by joelmartinez
And that right there is part of the appeal of XML ... Even if I had never seen the spec for a document I was looking at (as with this), I'd be able to figure it out just by looking at it and work it into my app.

You're talking a different thing. The whole point of the s-expression example is that it can't easily be expressed in XML. Any result is likely to be less readable.

You should not be making wild claims that you can understand all XML documents just by looking at them. Just because a tag has a particular name does not mean you should be guessing at the semantics of the tag, or that you will guess correctly. You're being rather naive about things here.

quote:
I think we're both starting to talk about totally different things here. To me, XML is simply a means of storing information ... not using it as a scripting language, or anything else as you seem to be implying (or the posts for that matter).

You're absolutely missing the point, so it's no wonder you think I'm talking about something different. The point being that each and every useful piece of data in a system has some semantic meaning, and the semantics have to be conveyed somewhere. Nobody's talking about a scripting language (although you might like to note XML is indeed being adapted to scripting uses, such as XSLT).

quote:
Perfect example is SVG. What better way to store vector graphics than XML.

Well, isn't it rather obvious that I'd suggest s-expressions as a better way?

quote:
This way, the file can be read and modified very easily by any application without having to know some obscure binary file format.

I've not mentioned binary formats. Please try and stay on track. If we're talking cross purposes, it's because you are straying from the topic. Let me remind you that Themonkster claimed nothing else has the flexibility of XML, to which I replied s-expressions have all the flexibility and more. Since then, you have argued against s-expressions on the basis of:

a) Kaz's example of something XML cannot neatly express is difficult to understand;

b) XML is better than CSV;

c) XML is better than binary.

It is possible that any symbolic expression can be recast as an XML document, with the result almost always being more verbose, and possibly more complex due to the limited semantics of XML. This is directly analogous to arguments of Turing completeness. Quite simply, s-expressions are a far superior medium for conveying structure and semantics than is XML. Read the Usenet posts again.

[edited by - SabreMan on February 12, 2003 12:26:20 PM]

Nice professional attitude you have there sabreman.

to address my previous post as bullshit is a bit lame.

Ever heard of SOAP.

it seems to me that you just are not willing to see any of the postive side of XML.

back to my first post and the comment you said was bullshit.

You do not need to know anything about another system when using XML as the bridge between all you need to know about is the data and XML gives you that.

an example is in the company I work in where we have several systems running together and we are always bring new ones online.

XML is a life saver because all the systems can comunicate in one voice.

when a new system comes in we only have to get it to understand XML(which most new systems do) and then it can communicate with all systems. if all of these systems had thier own format this would be a nightmare.

quote: Original post by Themonkster
Ever heard of SOAP.

Yes. What of it?

quote:
You do not need to know anything about another system when using XML as the bridge between all you need to know about is the data and XML gives you that.

Complete rubbish. Are you following the discussion whatsoever? What about if I invent an XML document containing any old rubbish and fire it at one of your systems? Will it understand it just because it''s XML? No, of course it won''t! Why? Because I have to know which fields I can send, what the semantics of each field are and what structure the fields have to adhere to. Maybe you have a front-end validation step which will return the document and tell me it''s full of crap, or maybe it will try and process it and fail without ever telling me there was a problem. If I really hit the bullseye, maybe the process will fall over. Who knows? Hence, a claim that XML frees me from the need to understand anything about your system is bullshit...

quote:
XML is a life saver because all the systems can comunicate in one voice.

...unadulterated.

quote:
when a new system comes in we only have to get it to understand XML(which most new systems do) and then it can communicate with all systems.

It also has to understand the document format, regardless of how many times you claim otherwise.

quote:
if all of these systems had thier own format this would be a nightmare.

You''re missing the point. Let''s try again: they can all have the same common file formats without XML.

Sabreman ... no one is saying that any system will magically know the meaning of a field just because it''s XML. We''re only saying that it''s easier as a developer to deal with a file laid out in XML. You can say that it''s easier for you to deal with fields that look like 0-87234p5;sdf8723lk, but that''s your opinion at this point.

Only an idiot would think that any technology would free you of the need to know and validate the content and layout of a file coming into your system. Apparently we have to say it explicitly for you to understand.

And as far as SOAP is concerned, that''s a very pertinent example because the semantics of the SOAP specification have been standardized, and as such, many many tools have been developed that can easily let you send data over the wire without worrying about little details like protocols, data layout, etc...


With SOAP, you DON''T have to know anything about another system ... all you have to do is specify that your web service will take any number of arguments, each strongly typed .. and your client sends it your way.
It''s exactly like a function in a class ... the function doesn''t care where that int came from, or where that string came from. as long as it''s sitting pretty in the argument list, it processes it, and returns a result.

quote: Let''s try again: they can all have the same common file formats without XML

You''re absolutely right ... feel free to use whatever convoluted file format you wish. I for one will continue to use XML because of the ease with which it allows me to store and transfer data.

Joel Martinez
http://www.codecube.net/