Hi,

I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]!

This is the project I'm working on for GSoC 2016. It aims to become a substitution for Phobos std.xml. Now you can easily try it and provide some feedback. I will soon create a WIP PR on the Phobos repository.

I suggest you to depend on ~master instead of v0.1.0, as bugfixes and enhancements are added on a daily basis (v0.1.0 is already one commit behind!)

Current limitations:
1) The documentation [2] is very limited;
2) Some advanced DOM methods are not completely implemented;
3) Some advanced features (e.g. DTD validation, namespace checks) are not yet available.

If you find any issue / have any suggestion, please file an issue on Github [3].

Thank you.

[1] https://code.dlang.org/packages/std-experimental-xml
[2] https://lodo1995.github.io/experimental.xml/
[3] https://github.com/lodo1995/experimental.xml

On 7/30/16 5:26 AM, Lodovico Giaretta wrote:
> Hi,
>
> I'm proud to announce that std.experimental.xml v0.1.0 is available on
> DUB [1]!
>
> This is the project I'm working on for GSoC 2016. It aims to become a
> substitution for Phobos std.xml. Now you can easily try it and provide
> some feedback. I will soon create a WIP PR on the Phobos repository.
>
> I suggest you to depend on ~master instead of v0.1.0, as bugfixes and
> enhancements are added on a daily basis (v0.1.0 is already one commit
> behind!)
>
> Current limitations:
> 1) The documentation [2] is very limited;
> 2) Some advanced DOM methods are not completely implemented;
> 3) Some advanced features (e.g. DTD validation, namespace checks) are
> not yet available.
>
> If you find any issue / have any suggestion, please file an issue on
> Github [3].
>
> Thank you.
>
> [1] https://code.dlang.org/packages/std-experimental-xml
> [2] https://lodo1995.github.io/experimental.xml/
> [3] https://github.com/lodo1995/experimental.xml

Good to see this advancing!

I'm looking at the cursor API and like what I see.

A couple things:
1) I see struct Cursor is not tagged for documentation, yet all it's members are. Your docs are missing out on a lot of stuff here! This might be true elsewhere too, make sure you tag types for documentation or the members won't show up in the docs.
2) The function "exit", I don't like. This is bikeshedding, but I just don't like the possibility that to conflate with C exit. I don't have a good replacement name for enter/exit, so this comment is pretty minor.

-Steve

On Sunday, 31 July 2016 at 12:04:18 UTC, Steven Schveighoffer wrote:
> On 7/30/16 5:26 AM, Lodovico Giaretta wrote:
>> [...]
> Good to see this advancing!
>
> I'm looking at the cursor API and like what I see.

Good to know. The cursor API is the central concept of the library, even if it will probably not be directly used by many.

> A couple things:
> 1) I see struct Cursor is not tagged for documentation, yet all it's members are. Your docs are missing out on a lot of stuff here! This might be true elsewhere too, make sure you tag types for documentation or the members won't show up in the docs.

You are right. Many things are only partially documented. I'm working to improve the situation. For now, you can find the documentation of Cursor in std.experimental.xml.isCursor, as this is in fact where it belongs. I will definitely mark struct Cursor for documentation, and add the relevant link to template isCursor.

> 2) The function "exit", I don't like. This is bikeshedding, but I just don't like the possibility that to conflate with C exit. I don't have a good replacement name for enter/exit, so this comment is pretty minor.

I don't agree with you on this. But I'm not too attached to that name either, so if anyone can suggest a better name pair for enter/exit, I have no problem in changing it. In general, I'm open to every kind of change that would ease usage and understanding.

Thank you for your feedback.

On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta wrote:
> Hi,
>
> I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]!
>
> This is the project I'm working on for GSoC 2016. It aims to become a substitution for Phobos std.xml. Now you can easily try it and provide some feedback. I will soon create a WIP PR on the Phobos repository.
>
> I suggest you to depend on ~master instead of v0.1.0, as bugfixes and enhancements are added on a daily basis (v0.1.0 is already one commit behind!)
>
> Current limitations:
> 1) The documentation [2] is very limited;
> 2) Some advanced DOM methods are not completely implemented;
> 3) Some advanced features (e.g. DTD validation, namespace checks) are not yet available.
>
> If you find any issue / have any suggestion, please file an issue on Github [3].
>
> Thank you.
>
> [1] https://code.dlang.org/packages/std-experimental-xml
> [2] https://lodo1995.github.io/experimental.xml/
> [3] https://github.com/lodo1995/experimental.xml

I have two comments.

What is the plan for the string interner and the allocator-based appender ?

They are neither part of the package, nor proposed in phobos, it seems that you'll encounter a problme in the package structure itself. This is also problemtaic now if I want to test it I have to add 3 import paths to sc.conf.

I suggest you either to propose them for phobos or to add them in a subpackage "internal" **inside xml** (or in a big internal.d module) like it's done for several phobos packages (algos, ndslices).

_____

I see a naming problem in you "fast" strings: fastIndexOf, fastEqual etc.

This is not good: does it mean that phobos's equivalent are slow ? Does it mean that you'll also propose slow equivalents (This is absurd, but it shows the problem).

On Sunday, 31 July 2016 at 15:28:14 UTC, LaTeigne wrote:
> On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta wrote:
>> Hi,
>>
>> I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]!
>>
>> This is the project I'm working on for GSoC 2016. It aims to become a substitution for Phobos std.xml. Now you can easily try it and provide some feedback. I will soon create a WIP PR on the Phobos repository.
>>
>> I suggest you to depend on ~master instead of v0.1.0, as bugfixes and enhancements are added on a daily basis (v0.1.0 is already one commit behind!)
>>
>> Current limitations:
>> 1) The documentation [2] is very limited;
>> 2) Some advanced DOM methods are not completely implemented;
>> 3) Some advanced features (e.g. DTD validation, namespace checks) are not yet available.
>>
>> If you find any issue / have any suggestion, please file an issue on Github [3].
>>
>> Thank you.
>>
>> [1] https://code.dlang.org/packages/std-experimental-xml
>> [2] https://lodo1995.github.io/experimental.xml/
>> [3] https://github.com/lodo1995/experimental.xml
>
> I have two comments.
>
> What is the plan for the string interner and the allocator-based appender ?
>
> They are neither part of the package, nor proposed in phobos, it seems that you'll encounter a problme in the package structure itself. This is also problemtaic now if I want to test it I have to add 3 import paths to sc.conf.
>
> I suggest you either to propose them for phobos or to add them in a subpackage "internal" **inside xml** (or in a big internal.d module) like it's done for several phobos packages (algos, ndslices).
>
> _____
>
> I see a naming problem in you "fast" strings: fastIndexOf, fastEqual etc.
>
> This is not good: does it mean that phobos's equivalent are slow ? Does it mean that you'll also propose slow equivalents (This is absurd, but it shows the problem).

Thank you for your comments.

Talking about your points:
1) the interner shall really go away before inclusion in Phobos; it is unneeded; its code is already partially duplicated in CopyingCursor (std.experimental.xml.cursor); but it would be good to have something like this in Phobos, somewhere in the future.
2) The appender is needed, as the Phobos one does not work with custom allocators; I don't have the time to polish it for Phobos adoption, so putting it in an internal xml submodule may be a great idea.
3) The fastXXX functions are intended for internal usage; they will have package protection in the final library (I really forgot about this thing; thanks).

I will tag v0.1.1 late this night, with some fixes based on the feedback from you and Steven.

Thank you again.

On Sunday, 31 July 2016 at 15:36:47 UTC, Lodovico Giaretta wrote:
> On Sunday, 31 July 2016 at 15:28:14 UTC, LaTeigne wrote:
>> On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta
> Thank you for your comments.
>
> Talking about your points:
> 1) the interner shall really go away before inclusion in Phobos; it is unneeded; its code is already partially duplicated in CopyingCursor (std.experimental.xml.cursor); but it would be good to have something like this in Phobos, somewhere in the future.
> 2) The appender is needed, as the Phobos one does not work with custom allocators; I don't have the time to polish it for Phobos adoption, so putting it in an internal xml submodule may be a great idea.

Yes that's the most reasonable solution, unless someone has the time to polish it for you and enough karma to get it pulled in the allocator package (very unlikely as adding new stuffs in phobos is usually not a piece of cake. Anyway it would really have its place there since there's already all the array routines: make expand shrink etc.)

> 3) The fastXXX functions are intended for internal usage; they will have package protection in the final library (I really forgot about this thing; thanks).
>
> I will tag v0.1.1 late this night

Ok, I'm gonna check this tomorrow.

On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta wrote:
> Hi,
>
> I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]!
>
>
> If you find any issue / have any suggestion, please file an issue on Github [3].
>
> Thank you.

Why is it 15 files when kxml is only one?

On Sunday, 31 July 2016 at 18:38:32 UTC, Guillaume Piolat wrote:
> On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta wrote:
>> Hi,
>>
>> I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]!
>>
>>
>> If you find any issue / have any suggestion, please file an issue on Github [3].
>>
>> Thank you.
>
> Why is it 15 files when kxml is only one?

kxml is way more than a file. You may say that its parser is just a file. In std.experimental.xml, the parser is at most three files (it depends on what you mean by parser), not fifteen.

kxml is also way limited with respect to std.experimental.xml. It does not support many features, like custom allocators (because they don't exist in Java). It does not have to strive to be @nogc (because it does not exist in Java). It does not support high customization, with custom lexers, pluggable validations, full DOM Level 3 support, with the ability for the user to provide a custom DOM implementation and have the DOMBuilder use it instead of the default provided DOM implementation. It does not support SAX with DbI on the handler type. It does not support outputting XML using a custom formatter, again with DbI.

Also keep in mind that std.experimental.xml contains LOTS of lines of unittests and some code is there just because Phobos does not provide some essential tools for the job.

It is true that I could merge some of these files, as they are almost all quite short, but I prefer them this way, cause they are easier to handle.

On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta wrote:
>
> kxml is also way limited with respect to std.experimental.xml. It does not support many features, like custom allocators (because they don't exist in Java). It does not have to strive to be @nogc (because it does not exist in Java). It does not support high customization, with custom lexers, pluggable validations, full DOM Level 3 support, with the ability for the user to provide a custom DOM implementation and have the DOMBuilder use it instead of the default provided DOM implementation. It does not support SAX with DbI on the handler type. It does not support outputting XML using a custom formatter, again with DbI.

Okay, just wanted to know what we are buying with (supposedly) more code.
For reference I was speaking of the D kxml package, which is a DOM parser than can range-iterate on nodes using XPath.

On Monday, 1 August 2016 at 07:38:29 UTC, Guillaume Piolat wrote:
> On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta wrote:
>>
>> kxml is also way limited with respect to std.experimental.xml. It does not support many features, like custom allocators (because they don't exist in Java). It does not have to strive to be @nogc (because it does not exist in Java). It does not support high customization, with custom lexers, pluggable validations, full DOM Level 3 support, with the ability for the user to provide a custom DOM implementation and have the DOMBuilder use it instead of the default provided DOM implementation. It does not support SAX with DbI on the handler type. It does not support outputting XML using a custom formatter, again with DbI.
>
> Okay, just wanted to know what we are buying with (supposedly) more code.
> For reference I was speaking of the D kxml package, which is a DOM parser than can range-iterate on nodes using XPath.

Ouch. Looks like I misunderstood you then. I apologize.

I don't know anything about that D package, but I can safely assume that this library will provide more functionalities and (most of all) more customization points. It's designed as a collection of components, each of with can be customized or even substituted with a user defined one. This is what such a big quantity of code will buy.

There are various principles one can use when building a library. In this case I didn't choose minimality. I prefered extensibility and customizability.