On Thursday, 18 February 2016 at 15:39:01 UTC, Robert burner Schadek wrote:
> On Thursday, 18 February 2016 at 12:30:29 UTC, Andrei Alexandrescu wrote:
>>
>> Would the measuring be possible with 2995 as a dub package? -- Andrei
>
> yes, after have synced the dub package to the PR

brought the dub package up to date with the PR (v0.0.6)

On Friday, 19 February 2016 at 12:13:53 UTC, Chris wrote:
> On Sunday, 3 May 2015 at 17:47:15 UTC, Joakim wrote:
>> On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek wrote:
>>> std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it:
>>>
>>> - SAX and DOM parser
>>> - in-situ / slicing parsing when possible (forward range?)
>>> - compile time switch (CTS) for lazy attribute parsing
>>> - CTS for encoding (ubyte(ASCII), char(utf8), ... )
>>> - CTS for input validating
>>> - performance
>>>
>>> Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2
>>>
>>> Please post you feature requests, and please keep the posts DRY and on topic.
>>
>> My request: just skip it.  XML is a horrible waste of space for a standard, better D doesn't support it well, anything to discourage it's use.  I'd rather see you spend your time on something worthwhile.  If data formats are your thing, you could help get Ludwig's JSON stuff in, or better yet, enable some nice binary data format.
>
> Glad to hear that someone is working on XML support. We cannot just "skip it". XML/HTML like mark up comes up all the time, here and there. I recently had to write a mini-parser (nowhere near the stuff Robert is doing, just a quick fix!) to extract data from XML input. This has nothing to do with personal preferences, it's just there [1] and has to be dealt with.
>
> [1] https://en.wikipedia.org/wiki/Speech_Synthesis_Markup_Language

Then write a good XML extraction-only library and dub it.  I see no reason to include this in Phobos, which will encourage those who don't know any better to use it, since it comes with the compiler.  I'll close with a quote from Saint Linus of Torvalds, which I was unaware of till a couple days ago:

"XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist."
https://en.wikiquote.org/wiki/Linus_Torvalds#2014

On Tuesday, 23 February 2016 at 11:22:23 UTC, Joakim wrote:
> Then write a good XML extraction-only library and dub it. I see no reason to include this in Phobos
You won't be able to sleep if it will be in Phobos?

I use XML and I don't like check tons of side libraries for see which will be good for me, which have support (bugfixes), which will have support in some years, etc.
Lot of systems already using XML and any serious language _must_ have official support for it.

> If data formats are your thing, you could help get Ludwig's JSON stuff in, or better yet, enable some nice binary data format.
If it better for you, it not mean that it will better for everyone.

If you really want to be serious about the XML package, then I humbly believe implementing the commonly-known DOM interfaces is a must. Luckily there is IDL available for it: https://www.w3.org/TR/DOM-Level-2-Core/idl/dom.idl . Also, speaking about DOM, all levels need to be supported!

Also, I would recommend borrowing the Tango's XML pull parser as it is blazingly fast.

Finally, perhaps integration with signal/slot module should perhaps be considered as well.

On Tuesday, 23 February 2016 at 12:46:38 UTC, Dmitry wrote:
> On Tuesday, 23 February 2016 at 11:22:23 UTC, Joakim wrote:
>> Then write a good XML extraction-only library and dub it. I see no reason to include this in Phobos
> You won't be able to sleep if it will be in Phobos?
>
> I use XML and I don't like check tons of side libraries for see which will be good for me, which have support (bugfixes), which will have support in some years, etc.
> Lot of systems already using XML and any serious language _must_ have official support for it.

So are you trying to say C/C++ are not serious languages :o)

Having said that, as much as I hate XML, basic support would be a nice feature for the language.

On Sunday, 21 February 2016 at 23:57:40 UTC, Adam D. Ruppe wrote:
> On Sunday, 21 February 2016 at 23:01:22 UTC, crimaniak wrote:
>> I will use it in my experiments, but getElementsBySelector() selector language need to be improved I think.
>
> What, specifically, do you have in mind?

Where is only a couple of ad-hoc checks for attributes values. This language is not XPath-compatible, so most easy way to cover a lot of cases is regex check for attributes. Something like "script[src/https:.+\\.googleapis\\.com/i]"

On Thursday, 25 February 2016 at 23:59:04 UTC, crimaniak wrote:
> Where is only a couple of ad-hoc checks for attributes values. This language is not XPath-compatible, so most easy way to cover a lot of cases is regex check for attributes. Something like "script[src/https:.+\\.googleapis\\.com/i]"

The css3 selector standard offers three substring search: [attr^=foo] if it begins with foo, [attr$=foo] if it ends with foo, and [attr*=foo] if it includes foo somewhere. dom.d supports all three now.

So for your regex, you could probably match: [attr*=googleapis.com] well enough.

On Wednesday, 24 February 2016 at 10:55:01 UTC, Dejan Lekic wrote:
> If you really want to be serious about the XML package, then I humbly believe implementing the commonly-known DOM interfaces is a must. Luckily there is IDL available for it: https://www.w3.org/TR/DOM-Level-2-Core/idl/dom.idl . Also, speaking about DOM, all levels need to be supported!

I agree, but the Document Object Model (DOM) is a huuuuuuuuge project.  It's a project I'd love to take an active hand in driving.  Also, DOM "level 4" is a living standard at whatwg.org, along with rules for parsing HTML.  (Which naturally means the rules are always changing.)

I have a partial implementation of DOM in JavaScript, so I am serious when I say it's going to take time.

Ideally (imho), we'd have a set of related packages, prefixed with std.web:
* html
* xml
* dom
* css
* javascript

(Yes, I'm suggesting a rename of std.xml2 to std.web.xml.)

But from what I can see, realistically the community is a long way from that.  I'm trying to write the SAX interfaces now.  I only have a limited amount of time to devote to this (a common complaint, I gather)...

Dejan Lekic <dejan.lekic@gmail.com> wrote:
> If you really want to be serious about the XML package, then I humbly believe implementing the commonly-known DOM interfaces is a must. Luckily there is IDL available for it: https://www.w3.org/TR/DOM-Level-2-Core/idl/dom.idl . Also, speaking about DOM, all levels need to be supported!
> 
> Also, I would recommend borrowing the Tango's XML pull parser as it is blazingly fast.
> 
> Finally, perhaps integration with signal/slot module should perhaps be considered as well.
> 

What's the usecase of DOM outside of browser interoperability/scripting? The API isn't particularly nice, especially in languages with a rich type system.

On Wednesday, 2 March 2016 at 02:50:22 UTC, Alex Vincent wrote:
> I agree, but the Document Object Model (DOM) is a huuuuuuuuge project.  It's a project I'd love to take an active hand in driving.


My dom.d implements a fair chunk of it already.

https://github.com/adamdruppe/arsd/blob/master/dom.d

Yes, indeed, it is quite a lot of code, but easy to use if you are familiar with javascript and css selectors.

http://dpldocs.info/experimental-docs/arsd.dom.html