Re: xmlParse with sockets.

Jan-Klaas Kollhof <keyjaque <at> yahoo.com> writes:

| The xmlParse() is nice but I would like to have more.
| 
| I would like to have an incremental parser, which can
| be fed with data. It should conviniently fire events 
| whenever elements are started and finished and when
| errors occur.

An incremental parser with information coming on events would be very useful 
yes, but only for parsing SVG that you can immediately append to the document.

| The main point though is to encode all data
| transmitted between server and client (or master
| slide) in XML not in some other encoding scheme.

This seems like a very odd decision, XML is verbose, it's difficult to parse, 
it's utility comes when you're talking between clients and servers you don't 
control, due to the security concerns of web applications you will be almost 
always controlling both ends of the situation, so using XML strengths would 
seem odd, then there are much easier things to parse you could use instead.

| I am sure a parser would help/ease application
| development.

Sure it would, so would lots of other things, and whilst I agree that an 
incremental XML parser could be useful, I don't agree that stuffing things into 
SVG clients simply because it makes a particular design choice easier than 
another.

| It would work much better with a sockets and 
| data exchange using XML would be even better and with
| an incremental parser it would be the simplest.

Could you explain why XML would be better than CSV here (and why JSON would be 
worse considering you have a high performance JSON interpreter anyway)

| <msg>
|    <cmd>post</cmd>
|    <to>#svg</to> 
|    <conent>Hello this is a message</content>
| </msg>
| 
| The above is much easier to interpret, too, compared
| to having to split up strings ...

Well, no it's quite hard to parse, the advantage is that there are XML parsers 
written..., ES comes with a parser that does:

{cmd:"post", to:"#svg", content:"Hello this is a message"};

to, why not use that, no need to burden the SVG implementors at all then.

Jim.

Received on Thursday, 11 March 2004 13:21:06 UTC