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.

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.

- CTS to disable parsing location (line,column)

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.

That's not really an option considering the huge amount of XML data there is out there.

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.

I agree that JSON is superior through-and-through, but legacy support matters, and XML is in many places. It's good to have a quality XML parsing library.

On 5/3/2015 10:39 AM, Robert burner Schadek wrote:
> Please post you feature requests, and please keep the posts DRY and on topic.

Pipeline range interface, for example:

    source.xmlparse(configuration).whatever();

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.

Could possibly use pegged to do it?
It may simplify the parsing portion of it for you at least.

On 5/3/2015 10:39 AM, Robert burner Schadek wrote:
> - CTS for encoding (ubyte(ASCII), char(utf8), ... )

Encoding schemes should be handled by adapter algorithms, not in the XML parser itself, which should only handle UTF8.

On 5/3/2015 10:39 AM, Robert burner Schadek wrote:
> Please post you feature requests, and please keep the posts DRY and on topic.

Try to design the interface to it so it does not inherently require the implementation to allocate GC memory.

Can it lazily reads huge files (files greater than memory)?