Re: [dev] Some thoughts about XML
2013/10/24 Bobby Powers bobbypow...@gmail.com: I think Russ Cox said it very well[1]: Mapping between XML elements and data structures is inherently flawed: an XML element is an order-dependent collection of anonymous values, while a data structure is an order-independent collection of named values. See [...] json for a textual representation more suitable to data structures. 1 - http://tip.golang.org/src/pkg/encoding/xml/read.go?s=257:579#L7 Yeah. For documents, XML suits more, because (reading) order usually matters and names are given through elements like captions.
Re: [dev] Some thoughts about XML
Alexander S. alex0pla...@gmail.com wrote: 2013/10/24 Mihail Zenkov mihail.zen...@gmail.com: 2013/10/23, Alexander S. alex0pla...@gmail.com: I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language. Why? ol li Lack of proper hierarchy, for one; li Lack of proper heterogenous containers, for two; libThe most important one/b: lack of multiline strings. /ol p Try to express something as simple as imy answer/i (which is rather trivial HTML snippet) in .ini format. /p [body] content=%ol%%p% [ol] style=list-style-type: decimal content=%li.1%%li.2%%li.3 [li] style=display: list-item content1=Lack of proper hierarchy, for one; content2=Lack of proper heterogeneous containers, for two; content3=%b%:\nlack of multiline strings. [b] style=font-weight: bold content=The most important one [p] style=display: block content=Try to express something as simple as %i% (which is\nrather trivial HTML snippet) in .ini format. [i] style=font-style: italic content=my answer
Re: [dev] Some thoughts about XML
On 2013-10-24 01:04, Samuel Holland wrote: [body] content=%ol%%p% [ol] style=list-style-type: decimal content=%li.1%%li.2%%li.3 [li] style=display: list-item content1=Lack of proper hierarchy, for one; content2=Lack of proper heterogeneous containers, for two; content3=%b%:\nlack of multiline strings. [b] style=font-weight: bold content=The most important one [p] style=display: block content=Try to express something as simple as %i% (which is\nrather trivial HTML snippet) in .ini format. [i] style=font-style: italic content=my answer I'm hoping this is devil's advocate, this is the worst thing I've ever seen. pgpZXRVUJT_Wr.pgp Description: PGP signature
Re: [dev] Some thoughts about XML
On 2013-10-24 14:43, Chris Down wrote: On 2013-10-24 01:04, Samuel Holland wrote: [body] content=%ol%%p% [ol] style=list-style-type: decimal content=%li.1%%li.2%%li.3 [li] style=display: list-item content1=Lack of proper hierarchy, for one; content2=Lack of proper heterogeneous containers, for two; content3=%b%:\nlack of multiline strings. I'm hoping this is devil's advocate, this is the worst thing I've ever seen. This is criticism by proof of concept. I award 100 points to Ravenclaw!
Re: [dev] Some thoughts about XML
Chris Down ch...@chrisdown.name wrote: On 2013-10-24 01:04, Samuel Holland wrote: [body] content=%ol%%p% [ol] style=list-style-type: decimal content=%li.1%%li.2%%li.3 [li] style=display: list-item content1=Lack of proper hierarchy, for one; content2=Lack of proper heterogeneous containers, for two; content3=%b%:\nlack of multiline strings. [b] style=font-weight: bold content=The most important one [p] style=display: block content=Try to express something as simple as %i% (which is\nrather trivial HTML snippet) in .ini format. [i] style=font-style: italic content=my answer I'm hoping this is devil's advocate, this is the worst thing I've ever seen. Yes, it was. The variable substitution is entirely made up, but what's worse is that almost every line of the Wikipedia page starts with some implementations... What I have been giving thought to is a representation using JSON, where each element is an array. The first member is a CSS selector, and subsequent members are strings and more arrays. That way you keep ordering and small size, yet can still mix text and elements.
Re: [dev] Some thoughts about XML
2013/10/24 Samuel Holland sam...@sholland.net: [body] content=%ol%%p% [ol] style=list-style-type: decimal content=%li.1%%li.2%%li.3 [li] style=display: list-item content1=Lack of proper hierarchy, for one; content2=Lack of proper heterogeneous containers, for two; content3=%b%:\nlack of multiline strings. [b] style=font-weight: bold content=The most important one [p] style=display: block content=Try to express something as simple as %i% (which is\nrather trivial HTML snippet) in .ini format. [i] style=font-style: italic content=my answer I didn't say it was impossible, mind you. I just said it would be the opposite of okay. Thanks for clearly demonstating my point :).
Re: [dev] Some thoughts about XML
2013/10/24 Charlie Kester corky1...@comcast.net: So don't use it as a markup language. As far as I know, it was never claimed to be fit for that purpose. Um. 2013/10/23 Mihail Zenkov mihail.zen...@gmail.com: It not mention good xml alternative: TOML https://github.com/mojombo/toml 1) TOML is basically .ini on steroids, 2) XML is a markup language, 3) anything that claims to be xml alternative ought to be a markup language. Personally, I'm okay with XML, and feel like Archangel Uriel, may he rest in peace, was slightly exaggerating. XSLT may be horrid, though, and XML is maybe *too* verbose, but the idea of having a structure as a building block is totally okay with me. There is expat parser, and who needs anything else. Using XML for simple, non-hierarchical config files is just plain wrong, not because XML is bad, but because it is misapplied. Using XML for storing Rhythmbox music database is wrong for the same reason. XML is for documents.
Re: [dev] Some thoughts about XML
2013/10/24, Alexander S. alex0pla...@gmail.com: Personally, I'm okay with XML, and feel like Archangel Uriel, may he rest in peace, was slightly exaggerating. XSLT may be horrid, though, and XML is maybe *too* verbose, but the idea of having a structure as a building block is totally okay with me. There is expat parser, and who needs anything else. Using XML for simple, non-hierarchical config files is just plain wrong, not because XML is bad, but because it is misapplied. Using XML for storing Rhythmbox music database is wrong for the same reason. XML is for documents. I think Russ Cox said it very well[1]: Mapping between XML elements and data structures is inherently flawed: an XML element is an order-dependent collection of anonymous values, while a data structure is an order-independent collection of named values. See [...] json for a textual representation more suitable to data structures. 1 - http://tip.golang.org/src/pkg/encoding/xml/read.go?s=257:579#L7
Re: [dev] Some thoughts about XML
the format of ini files are a problem for you?? On 10/23/13, Thorsten Glaser t...@mirbsd.de wrote: Mihail Zenkov dixit: It not mention good xml alternative: TOML Thank gods the time of Windows 3.x *.ini files is long gone. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Re: [dev] Some thoughts about XML
hiro dixit:
the format of ini files are a problem for you??
Multiple question marks, he said, are a sure sign of a diseased mind.
(Or something like that. It’s been some time since I last read him.)
On 10/23/13, Thorsten Glaser t...@mirbsd.de wrote:
Oh great, TOFU! Please read and honour
http://www.afaik.de/usenet/faq/zitieren/
next time.
But what do I expect from a Googlemail user.
*sigh*
Why does suckless seem to collect so many clueless people?
bye,
//mirabilos
--
Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [dev] Some thoughts about XML
Thorsten Glaser t...@mirbsd.de wrote: But what do I expect from a Googlemail user? Oh please tell me a good alternative free and reliable mail service. I hate Google. But all the others append ads. OT: XML is like cancer. It is disgusting to work with and disgusting to look at. And you really wanna get rid of it. But you can't without destroying everything around it.
[OT] eMail (was Re: [dev] Some thoughts about XML)
koneu dixit: Oh please tell me a good alternative free and reliable mail service. sendmail? postfix? There’s a lot of stuff around, and you can just run them for free on your own server. Easy to set up, too. (This is really stupid. Besides, you could just search around for unix shell accounts or related associations, such as trash.net or the SDF or gnook, who usually also offer SMTP. Yet, every self-respecting dev would rather host his eMail himself.) bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Re: [dev] Some thoughts about XML
On Tue, Oct 22, 2013 at 10:35:03PM +, Thorsten Glaser wrote: Mihail Zenkov dixit: It not mention good xml alternative: TOML Thank gods the time of Windows 3.x *.ini files is long gone. I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpSTaNbezzFN.pgp Description: PGP signature
Re: [dev] Some thoughts about XML
you guy bore me
On 10/23/13, Thorsten Glaser t...@mirbsd.de wrote:
hiro dixit:
the format of ini files are a problem for you??
Multiple question marks, he said, are a sure sign of a diseased mind.
(Or something like that. It’s been some time since I last read him.)
On 10/23/13, Thorsten Glaser t...@mirbsd.de wrote:
Oh great, TOFU! Please read and honour
http://www.afaik.de/usenet/faq/zitieren/
next time.
But what do I expect from a Googlemail user.
*sigh*
Why does suckless seem to collect so many clueless people?
bye,
//mirabilos
--
Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [dev] Some thoughts about XML
2013/10/24 William Giokas 1007...@gmail.com: On Tue, Oct 22, 2013 at 10:35:03PM +, Thorsten Glaser wrote: Mihail Zenkov dixit: It not mention good xml alternative: TOML Thank gods the time of Windows 3.x *.ini files is long gone. I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language.
Re: [dev] Some thoughts about XML
On Thu, Oct 24, 2013 at 02:20:29AM +0400, Alexander S. wrote: 2013/10/24 William Giokas 1007...@gmail.com: On Tue, Oct 22, 2013 at 10:35:03PM +, Thorsten Glaser wrote: Mihail Zenkov dixit: It not mention good xml alternative: TOML Thank gods the time of Windows 3.x *.ini files is long gone. I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language. This is true. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpycutvYk6Pf.pgp Description: PGP signature
Re: [dev] Some thoughts about XML
2013/10/23, Alexander S. alex0pla...@gmail.com: I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language. Why?
Re: [dev] Some thoughts about XML
2013/10/24 Mihail Zenkov mihail.zen...@gmail.com: 2013/10/23, Alexander S. alex0pla...@gmail.com: I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language. Why? ol li Lack of proper hierarchy, for one; li Lack of proper heterogenous containers, for two; libThe most important one/b: lack of multiline strings. /ol p Try to express something as simple as imy answer/i (which is rather trivial HTML snippet) in .ini format. /p
Re: [dev] Some thoughts about XML
On Wed 23 Oct 2013 at 16:44:34 PDT Alexander S. wrote: 2013/10/24 Mihail Zenkov mihail.zen...@gmail.com: 2013/10/23, Alexander S. alex0pla...@gmail.com: I'm confused as to what is wrong with the .ini style configurations. They're not just used in Windows, they're used in many other places that require simple, easy to use configurations. Python uses it, there are C api's for it, etc. So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language. Why? ol li Lack of proper hierarchy, for one; li Lack of proper heterogenous containers, for two; libThe most important one/b: lack of multiline strings. /ol p Try to express something as simple as imy answer/i (which is rather trivial HTML snippet) in .ini format. /p So don't use it as a markup language. As far as I know, it was never claimed to be fit for that purpose.
Re: [dev] Some thoughts about XML
2013/10/23, Alexander S. alex0pla...@gmail.com: So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language. Why? ol li Lack of proper hierarchy, for one; li Lack of proper heterogenous containers, for two; libThe most important one/b: lack of multiline strings. /ol p Try to express something as simple as imy answer/i (which is rather trivial HTML snippet) in .ini format. /p Thanks for clear answer :)
Re: [dev] Some thoughts about XML
2013/10/21, hiro 23h...@gmail.com: It seems like some subscribers haven't read the bible of suckless yet. http://harmful.cat-v.org/software/ and http://harmful.cat-v.org/software/xml/ It not mention good xml alternative: TOML https://github.com/mojombo/toml
Re: [dev] Some thoughts about XML
2013/10/23 Mihail Zenkov mihail.zen...@gmail.com: 2013/10/21, hiro 23h...@gmail.com: It seems like some subscribers haven't read the bible of suckless yet. http://harmful.cat-v.org/software/ and http://harmful.cat-v.org/software/xml/ It not mention good xml alternative: TOML https://github.com/mojombo/toml no multiline strings obscure syntax for declaring hashes when I change hash top name, I need to change all that are nested Heck, even Python ConfigObj would be nicer to use for documents. How will you type texts in *this*? \n all the way?
Re: [dev] Some thoughts about XML
Mihail Zenkov dixit: It not mention good xml alternative: TOML Thank gods the time of Windows 3.x *.ini files is long gone. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Re: [dev] Some thoughts about XML
It seems like some subscribers haven't read the bible of suckless yet. http://harmful.cat-v.org/software/ and http://harmful.cat-v.org/software/xml/ On 10/20/13, Szymon Olewniczak szymon.olewnic...@rid.pl wrote: On Sun, Oct 20, 2013 at 01:02:34AM +0200, Dmitrij D. Czarkoff wrote: Evan Buswell said: But OTOH, I do like the idea of separating the translation-to-html bit from the generate-sensible-output bit. XSLT may have done this poorly, but it's on the right track (and what else works better for this, Awk? Perl? m4?). I mean, I take the point that we can't really make the web stack all that much better, but at least we can containerize suck? Yes? Containerize suck of web stack? It is already containerized in browsers - choose the one that sucks less. See, the problem with web stack are not somewhere between the stack and the rest of your software and data. You readily may have your data in whatever format you want and share it via whatever protocol you like. Eg. you may have a bunch of JSON files accessible via their URLs as they are and via werc (or your custom CGI script) as HTML. The problem with web stack is the ugliness of web stack itself, and there is no workaround for that. But think that we need to find something between. If we develop our own window manager on top of X11(which itself isn't very suckless), its useful beouse it uses X11 (something that is standrad now) and it let us use all X11 apps in a less sucky way. So I think that saying - all modern web sucks(which is right in fact) - let's make something completly diffirent is like saying - X11 sucks, let's create something that can replace it. I'm serching for something similar as dwm in the web services world. We cannnot force everyone to use something diffirent than HTML and HTTP becouse noone want a huge revolution(users, web browsers and http servers developers). But maybe we can use this tools to create something less sucky, something that would make the web a better place. I don't want to starting a new project that will make the web worst place. I believe that web developdent can be done better rigth now and I want to show that it's possible. BR, Szymon
Re: [dev] Some thoughts about XML
On Sun, Oct 20, 2013 at 01:02:34AM +0200, Dmitrij D. Czarkoff wrote: Evan Buswell said: But OTOH, I do like the idea of separating the translation-to-html bit from the generate-sensible-output bit. XSLT may have done this poorly, but it's on the right track (and what else works better for this, Awk? Perl? m4?). I mean, I take the point that we can't really make the web stack all that much better, but at least we can containerize suck? Yes? Containerize suck of web stack? It is already containerized in browsers - choose the one that sucks less. See, the problem with web stack are not somewhere between the stack and the rest of your software and data. You readily may have your data in whatever format you want and share it via whatever protocol you like. Eg. you may have a bunch of JSON files accessible via their URLs as they are and via werc (or your custom CGI script) as HTML. The problem with web stack is the ugliness of web stack itself, and there is no workaround for that. But think that we need to find something between. If we develop our own window manager on top of X11(which itself isn't very suckless), its useful beouse it uses X11 (something that is standrad now) and it let us use all X11 apps in a less sucky way. So I think that saying - all modern web sucks(which is right in fact) - let's make something completly diffirent is like saying - X11 sucks, let's create something that can replace it. I'm serching for something similar as dwm in the web services world. We cannnot force everyone to use something diffirent than HTML and HTTP becouse noone want a huge revolution(users, web browsers and http servers developers). But maybe we can use this tools to create something less sucky, something that would make the web a better place. I don't want to starting a new project that will make the web worst place. I believe that web developdent can be done better rigth now and I want to show that it's possible. BR, Szymon
Re: [dev] Some thoughts about XML
Szymon Olewniczak said: I'm serching for something similar as dwm in the web services world. The thing you were talking about initially - if I got you right - is another CMS engine. You may look at werc for a good implementation of this idea. If you want something more lightweight, you may have your data in JSON and provide URLs for raw data together with HTML presentation either via JS or your custom CGI script. We cannnot force everyone to use something diffirent than HTML and HTTP becouse noone want a huge revolution(users, web browsers and http servers developers). What are you talking about? We are stuck with HTML+JS+CSS over HTTP with no possible workaround. (Apart from re-doing the web stack from scratch and mirroring it with HTML+JS+CSS over HTTP for unbelievers.) But maybe we can use this tools to create something less sucky, something that would make the web a better place. Better place undefined. Really, to date you suggested XML+XSLT, which doesn't sound like a workable replacement, leave alone suckless bit. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
HTML is there, other kinds of XML are avoidable. SVG is irrelevant, cause nobody uses it. Don't forget: you don't need to read XML specs to write working HTML. On 10/19/13, Alexander S. alex0pla...@gmail.com wrote: 2013/10/18 Dmitrij D. Czarkoff czark...@gmail.com: Szymon Olewniczak said: Another advantage of XML is its adaptation. We've already have MathML, SVG and many many others[1] all build on top of XML. SVG and MathML are probably the best arguments against XML ever. I am yet to see two SVG libraries that would render sufficiently complex spec-complient SVG equally. And I have no hope for seeing any spec-complient SVG rendering library ever. MathML is yet worse. To save words: http://aiju.de/rant/XML/MathML I'd not agree that SVG render problems are due to XML parsing. I think it's just that anything that attempts to draw SVG according to a spec must be *very* capable, with all those filters and transforms and animations and ecmascripts. It might as well be a TeX extension, and we would have the same (actually, probably even more) problems.
Re: [dev] Some thoughts about XML
Alexander S. said: SVG and MathML are probably the best arguments against XML ever. I am yet to see two SVG libraries that would render sufficiently complex spec-complient SVG equally. And I have no hope for seeing any spec-complient SVG rendering library ever. I'd not agree that SVG render problems are due to XML parsing. Neither do I. The XML-related problem with SVGs is that every library has its own view on splitting the data between tags, attributes and values. I had a couple of sessions of hand-editing SVG files to get them displayed properly, though from metadata it was obvious that files were generated by software. SVG software sucks really dramatically by the way. It is not uncommon to find an SVG that can be reduced to third of its size without data loss. hiro said: SVG is irrelevant, cause nobody uses it. It is used quite a lot, actually. Wikipedia is full of SVGs, and it is definitely the most common vector graphics format on the net. (Well, PDF is more common, but it is rarely used for vector graphics, I believe.) Don't forget: you don't need to read XML specs to write working HTML. HTML isn't XML. Valid XML parser isn't valid HTML parser. They tried to make HTML a strict subset of XML - XHTML Strict - but it didn't make it. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Szymon Olewniczak said:
s/HTML/XML+XSLT/g is quite a revolution.
But it's something whitch I can use in my application straight away
without forcing user to change their web browsers.
You aren't really about replacing HTML with XML+XSLT; you are about
*generating* HTML with XML+XSLT, are you?
It's about whole modern web stack and ways we can make it better,
without a huge revolution.
We can't.
1. We have nothing to do with its development.
2. It only gets worse over time.
3. It is {,mis,ab}used on such scale that it can't be sanitized.
You can't have a sane tool for doing everything.
--
Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
I loathe XML, but I think the OPs bigger point was: hey look, here is
a way that we can try and create a space between the suck of the web
and our code. So we support browsers through XSLT, and do something
slightly more sane with XML. I think that's a pretty valid suggestion.
IMO, this doesn't go far enough as XML is really not good for
anything. JSON is better for data (or a variant KSON I've been
playing with that adds symbolic references and uses binary instead of
utf-8 strings); RST is better for structured text---though I'm not
sure I really like any of the structured text formats.
But OTOH, I do like the idea of separating the translation-to-html bit
from the generate-sensible-output bit. XSLT may have done this poorly,
but it's on the right track (and what else works better for this, Awk?
Perl? m4?). I mean, I take the point that we can't really make the web
stack all that much better, but at least we can containerize suck?
Yes?
On Sat, Oct 19, 2013 at 11:54 AM, Evan Buswell ebusw...@gmail.com wrote:
I loathe XML, but I think the OPs bigger point was: hey look, here is a way
that we can try and create a space between the suck of the web and our code.
So we support browsers through XSLT, and do something slightly more sane
with XML. I think that's a pretty valid suggestion.
IMO, this doesn't go far enough as XML is really not a good for anything.
JSON is better for data (or a variant KSON I've been playing with that
adds symbolic references and binary instead of utf-8 strings); RST is better
for structured text---though I'm not sure I really like any of the
structured text formats.
But OTOH, I do like the idea of separating the translation-to-html bit from
the rest of it. I mean, I take the point that we can't really make the web
stack all that much better, but at least we can containerize suck? Yes?
On Oct 19, 2013 9:04 AM, Dmitrij D. Czarkoff czark...@gmail.com wrote:
Szymon Olewniczak said:
s/HTML/XML+XSLT/g is quite a revolution.
But it's something whitch I can use in my application straight away
without forcing user to change their web browsers.
You aren't really about replacing HTML with XML+XSLT; you are about
*generating* HTML with XML+XSLT, are you?
It's about whole modern web stack and ways we can make it better,
without a huge revolution.
We can't.
1. We have nothing to do with its development.
2. It only gets worse over time.
3. It is {,mis,ab}used on such scale that it can't be sanitized.
You can't have a sane tool for doing everything.
--
Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Evan Buswell dixit: playing with that adds symbolic references and uses binary instead of utf-8 strings); RST is better for structured text---though I'm not Oh yeah, let’s all do binary now instead of passing around plaintext! Wait. No! Pointing out Unix/Plan 9 way works just fine, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Re: [dev] Some thoughts about XML
Evan Buswell said: But OTOH, I do like the idea of separating the translation-to-html bit from the generate-sensible-output bit. XSLT may have done this poorly, but it's on the right track (and what else works better for this, Awk? Perl? m4?). I mean, I take the point that we can't really make the web stack all that much better, but at least we can containerize suck? Yes? Containerize suck of web stack? It is already containerized in browsers - choose the one that sucks less. See, the problem with web stack are not somewhere between the stack and the rest of your software and data. You readily may have your data in whatever format you want and share it via whatever protocol you like. Eg. you may have a bunch of JSON files accessible via their URLs as they are and via werc (or your custom CGI script) as HTML. The problem with web stack is the ugliness of web stack itself, and there is no workaround for that. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Evan Buswell said: I can care that this is UTF-8 when I need to, and not care otherwise. I would love to see the code that detects whether you care or not. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
I'm really not saying something very profound here, so I'm a bit confused by the sarcastic response. For certain things it's pointless and inefficient to parse something and then deparse it later. It's not like you're gonna put UTF-8 parsing into cat. On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Czarkoff czark...@gmail.com wrote: Evan Buswell said: I can care that this is UTF-8 when I need to, and not care otherwise. I would love to see the code that detects whether you care or not. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Evan Buswell said: I'm really not saying something very profound here, so I'm a bit confused by the sarcastic response. For certain things it's pointless and inefficient to parse something and then deparse it later. It's not like you're gonna put UTF-8 parsing into cat. This brings you into encoding detection and either assumptions or guessing. I just can't believe you're willingly dragging yourself into it. I really don't want some special support for utf-8 in cat, because my local files generally have the same encoding with my terminal, and I won't lose much resources when I have to cope with differently encoded files. But it has nothing to do with network-interfacing format, where any spec ambiguity directly translates into either loss of resources (bandwidth, time, processing power) or loss of clients. That's not to mention that you may have another encoding specified elsewhere in your delivery chain (eg. in http headers). -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Evan Buswell dixit:
like you're gonna put UTF-8 parsing into cat.
cat is just a sendfile, it’s not doing anything with the content.
On the other hand, for a data exchange format, some measure of
data types is a commodity. JSON is not binary-safe, true, but the
Unix/Plan 9 way doesn’t need it to be.
On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Czarkoff czark...@gmail.com
wrote:
Oh and, for fucks sake, learn writing eMails!
Read http://www.afaik.de/usenet/faq/zitieren/ (this has links to
the English and Dutch version as well).
bye,
//mirabilos
--
Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
[dev] Some thoughts about XML
Hi, everyone knows that XML has its defects but considering some of our discussions about suckless web ideas I think that XML + XSLT is quite a good solution - much better than plain HTML. Pages writen in XML has readable source and data can be accessed much more easily. In addition using of XML causes that we have API for each web page which is using it. Other disadvantage of XML - the large size of files (in compression with JSON) also isn't a big problem becouse when we use some compression algorithms (gzip for example), xml will compress much better and it's size will be similar to its JSON equivalent. Another advantage of XML is its adaptation. We've already have MathML, SVG and many many others[1] all build on top of XML. Persons who would like to use web browser to read the page can still do it (using XLST) and the person who would like to get some information from the page can also do it in easy way. At the and I want to ask you a question. What do you think would be the best solution for bulding websites which would look similar to this what we have now(gopher is great but ...) and would have easily accessible data for persons who want to use it in thay own applications? BR, Szymon [1]https://en.wikipedia.org/wiki/List_of_XML_markup_languages
Re: [dev] Some thoughts about XML
On Fri, 18 Oct 2013 14:44:55 +0200 Szymon Olewniczak szymon.olewnic...@rid.pl wrote: At the and I want to ask you a question. What do you think would be the best solution for bulding websites which would look similar to this what we have now(gopher is great but ...) and would have easily accessible data for persons who want to use it in thay own applications? Hi. It's impossible. Either you have application, or you have document. Websites of today want to be applications with precise visual representation. Website's design can blow up if you even change the font size. There should be separate web for applications (with something more appropriate than HTML/CSS/JS). There should be also separate web for documents (with something more appropriate than HTML/CSS/JS). I don't see any worldwide hope soon. XML+XLST certainly is not one. There is too much push for more brands and APIs, than for simple interaction between programs.
Re: [dev] Some thoughts about XML
Szymon Olewniczak dixit: Pages writen in XML has readable source No. Much like sendmail.cf, XML is a binary/object format and ought to be treated as such. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C
Re: [dev] Some thoughts about XML
On 2013-10-18 14:44, Szymon Olewniczak wrote: Pages writen in XML has readable source and data can be accessed much more easily. I don't even know what to say to this... pgp_Gvokspkmt.pgp Description: PGP signature
Re: [dev] Some thoughts about XML
Chris Down dixit: I don't even know what to say to this... Must be the full moon. First 20h “liking” kdbus, now this… bye, //mirabilos -- This space for rent.
Re: [dev] Some thoughts about XML
Chris Down said: On 2013-10-18 14:44, Szymon Olewniczak wrote: Pages writen in XML has readable source and data can be accessed much more easily. I don't even know what to say to this... Strictly speaking, I agree with OP on this: XML is much better then HTML (actually fault-tolerance reuired for HTML makes it much worse then otherwise nightmarish XML). That doesn't make XML usable though. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Szymon Olewniczak said: Another advantage of XML is its adaptation. We've already have MathML, SVG and many many others[1] all build on top of XML. SVG and MathML are probably the best arguments against XML ever. I am yet to see two SVG libraries that would render sufficiently complex spec-complient SVG equally. And I have no hope for seeing any spec-complient SVG rendering library ever. MathML is yet worse. To save words: http://aiju.de/rant/XML/MathML -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
On Oct 18, 2013, at 4:00 PM, Thorsten Glaser t...@mirbsd.de wrote: Must be the full moon. First 20h “liking” kdbus, now this… Winter is coming.
kdbus again (was: Re: [dev] Some thoughts about XML)
Greetings. On Fri, 18 Oct 2013 19:17:55 +0200 Thorsten Glaser t...@mirbsd.de wrote: Chris Down dixit: I don't even know what to say to this... Must be the full moon. First 20h “liking” kdbus, now this… It shouldn’t be using »dbus« because dbus is this [0]. But yes, with the local addresses all of the IP filtering logic will be reimplemented, just for the kernel. Just take the 127.0.0.0/8 network and add a default flag for not allowing any packet forwarding. If communication between two hosts in that network happen the kernel could use a special case to do more efficient data copying. Even systems not supporting the local special case could run services by just having TCP/IP implemented and a loopback device. All the logic already created for IP will be available. And it will teach people IP routing and filtering. Sincerely, Christoph Lohmann [0] http://dbus.freedesktop.org/doc/dbus-specification.html
Re: [dev] Some thoughts about XML
On Fri, Oct 18, 2013 at 06:48:06PM +0200, Dmitrij D. Czarkoff wrote: Chris Down said: On 2013-10-18 14:44, Szymon Olewniczak wrote: Pages writen in XML has readable source and data can be accessed much more easily. I don't even know what to say to this... Strictly speaking, I agree with OP on this: XML is much better then HTML (actually fault-tolerance reuired for HTML makes it much worse then otherwise nightmarish XML). That doesn't make XML usable though. I've started this topic becouse I'm woriking in a small family firm and we have decided that we need an new application to managing complaints, documentation, and several other things of our clients (I don't want to go into detail). So I'm thinking about model that would make it usable for peoples like me and for non-tech users. XML + XSLT is one of my ideas, another is one file web application based on JSON calls (maybe its better, what do you think?). I believe that we can make the web the better place without huge revolutino(such as changing HTTP to something else) or maybe I am wrong. BR, Szymon
Re: [dev] Some thoughts about XML
On 18/10/2013, Szymon Olewniczak szymon.olewnic...@rid.pl wrote: I believe that we can make the web the better place without huge revolutino s/HTML/XML+XSLT/g is quite a revolution. (such as changing HTTP to something else) Which is this about, HTTP or HTML? Pages writen in XML has readable source So have pages written in Microsoft Word; a read call will fill my buffer with it. Readable ≠ readily parsible.
Re: [dev] Some thoughts about XML
On 18/10/2013, Szymon Olewniczak szymon.olewnic...@rid.pl wrote: I believe that we can make the web the better place without huge revolutino s/HTML/XML+XSLT/g is quite a revolution. But it's something whitch I can use in my application straight away without forcing user to change their web browsers. (such as changing HTTP to something else) Which is this about, HTTP or HTML? It's about whole modern web stack and ways we can make it better, without a huge revolution. BR, Szymon
Re: [dev] Some thoughts about XML
Szymon Olewniczak dixit: s/HTML/XML+XSLT/g is quite a revolution. But it's something whitch I can use in my application straight away without forcing user to change their web browsers. But XSLT is a joke. Have you *seen* the lengths people go through to actually *do* anything in it? It may have seemed a good idea when Java™ was still “write once, run anywhere”… It's about whole modern web stack and ways we can make it better, without a huge revolution. Please read up on ROCA – http://roca-style.org/ – which I kinda like because it says your web “application” m̲u̲s̲t̲ work in Lynx, and any CSS and, possibly, ECMAscript may o̲n̲l̲y̲ be added in an unobtrusive way (e.g. to make things nicer, or to enable things like interactive statistic graphs that just don’t make any sense without, but n̲e̲v̲e̲r̲ to have any regular function of the application depend on it). It also uses REST, which means you get your share of the “modern web stack”. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999
Re: [dev] Some thoughts about XML
On Fri, Oct 18, 2013 at 3:09 PM, Szymon Olewniczak szymon.olewnic...@rid.pl wrote: I've started this topic becouse I'm woriking in a small family firm and we have decided that we need an new application to managing complaints, documentation, and several other things of our clients (I don't want to go into detail). So I'm thinking about model that would make it usable for peoples like me and for non-tech users. XML + XSLT is one of my ideas, another is one file web application based on JSON calls (maybe its better, what do you think?). I believe that we can make the web the better place without huge revolutino(such as changing HTTP to something else) or maybe I am wrong. JSON is much better than XML for passing data structures around and maintaining sanity.
Re: [dev] Some thoughts about XML
2013/10/18 Dmitrij D. Czarkoff czark...@gmail.com: Szymon Olewniczak said: Another advantage of XML is its adaptation. We've already have MathML, SVG and many many others[1] all build on top of XML. SVG and MathML are probably the best arguments against XML ever. I am yet to see two SVG libraries that would render sufficiently complex spec-complient SVG equally. And I have no hope for seeing any spec-complient SVG rendering library ever. MathML is yet worse. To save words: http://aiju.de/rant/XML/MathML I'd not agree that SVG render problems are due to XML parsing. I think it's just that anything that attempts to draw SVG according to a spec must be *very* capable, with all those filters and transforms and animations and ecmascripts. It might as well be a TeX extension, and we would have the same (actually, probably even more) problems.
