On 8/29/13 15:25, w0rp wrote:
> Hello everybody. I've been wondering, what are the current plans to
> replace std.xml? I'd like to help with the effort to get a final XML
> library in phobos. So, I have a few questions.
>
> First, and most importantly, what do we except out of a D XML library?
> I'd really like to have a discussion of the form, "Here is exactly the
> interface the structs/classes need to implement, go forth and
> implement." The general idea in my mind is "something SAX-like, with
> something a little DOM-like." I'm aware that std.xml has some issues
> support different encodings, so obvious that's included.
>
> Second, is there an existing library that has gotten close to meeting
> whatever we need for the first point? If so, how far away is it from
> being able to meet all of the requirements and become the standard
> library version?

Having been the lead programmer on the Microsoft XML team for three years, I can easily say that the most popular XML API [on MS stack] is the XmlReader and XLinq in .NET. (This has nothing to do with LINQ, by the way.)

I'd be willing to help make D versions of that, but my time is limited. But as usual, I don't think it's the actual coding that will take time. Designing a good interface is the hardest part, and I'd consider that part done.

L.

On 03/09/13 12:40, Lionello Lunesu wrote:
> On 8/29/13 15:25, w0rp wrote:
>> Hello everybody. I've been wondering, what are the current plans to
>> replace std.xml? I'd like to help with the effort to get a final XML
>> library in phobos. So, I have a few questions.
>>
>> First, and most importantly, what do we except out of a D XML library?
>> I'd really like to have a discussion of the form, "Here is exactly the
>> interface the structs/classes need to implement, go forth and
>> implement." The general idea in my mind is "something SAX-like, with
>> something a little DOM-like." I'm aware that std.xml has some issues
>> support different encodings, so obvious that's included.
>>
>> Second, is there an existing library that has gotten close to meeting
>> whatever we need for the first point? If so, how far away is it from
>> being able to meet all of the requirements and become the standard
>> library version?
>
> Having been the lead programmer on the Microsoft XML team for three
> years, I can easily say that the most popular XML API [on MS stack] is
> the XmlReader and XLinq in .NET. (This has nothing to do with LINQ, by
> the way.)
>
> I'd be willing to help make D versions of that, but my time is limited.
> But as usual, I don't think it's the actual coding that will take time.
> Designing a good interface is the hardest part, and I'd consider that
> part done.
>
> L.

For whoever ends up doing std.xml's replacement, it would be good if some of the lower level interfaces such as encode/decode (for escaping/unescaping within text) were exposed.  I'm finding the ones in std.xml useful for implementing markup in label widgets during my investigation into reimplementing the GTK+ (modified) interface in D.

Of course, there's always the chance that the new D xml API provides enough to make my markup code redundant.  It's possible that the current high level APIs in std.xml also provides enough make my work redundant but I decided not to investigate this possibility after I saw the "will be replaced by something different" warning.

Cheers
Peter

On 9/2/13 7:40 PM, Lionello Lunesu wrote:
> Having been the lead programmer on the Microsoft XML team for three
> years, I can easily say that the most popular XML API [on MS stack] is
> the XmlReader and XLinq in .NET. (This has nothing to do with LINQ, by
> the way.)
>
> I'd be willing to help make D versions of that, but my time is limited.
> But as usual, I don't think it's the actual coding that will take time.
> Designing a good interface is the hardest part, and I'd consider that
> part done.

This is great info, thanks.

Andrei

On Thursday, 29 August 2013 at 16:14:28 UTC, Michel Fortin wrote:
>
> I wrote something like that a while ago.
>
> It only accepted arrays as input because of the lack of a "buffered range" concept that'd allow lookahead and efficient slicing from any kind of range, but that could be retrofitted in. It implements pretty much all of the XML spec, except for documents having an internal subset (which is something a little arcane). It does not deal with namespaces either, I feel like that should be done a layer above, but I'm not entirely sure.
>
> Lower-level parser:
> http://michelf.ca/docs/d/mfr/xmltok.html
>
> Higher-level parser built on the first one:
> http://michelf.ca/docs/d/mfr/xml.html
>
> The code:
> http://michelf.ca/docs/d/mfr-xml-2010-10-19.zip
>
> That code hasn't been compiled in a while, but it used to work very well for me. Feel free to use as a starting point.

Can you push it to the github, please?

On 2013-09-03 16:11:37 +0000, "ilya-stromberg" <ilya-stromberg-2009@yandex.ru> said:

> On Thursday, 29 August 2013 at 16:14:28 UTC, Michel Fortin wrote:
>> 
>> I wrote something like that a while ago.
>> 
>> It only accepted arrays as input because of the lack of a "buffered range" concept that'd allow lookahead and efficient slicing from any kind of range, but that could be retrofitted in. It implements pretty much all of the XML spec, except for documents having an internal subset (which is something a little arcane). It does not deal with namespaces either, I feel like that should be done a layer above, but I'm not entirely sure.
>> 
>> Lower-level parser:
>> http://michelf.ca/docs/d/mfr/xmltok.html
>> 
>> Higher-level parser built on the first one:
>> http://michelf.ca/docs/d/mfr/xml.html
>> 
>> The code:
>> http://michelf.ca/docs/d/mfr-xml-2010-10-19.zip
>> 
>> That code hasn't been compiled in a while, but it used to work very well for me. Feel free to use as a starting point.
> 
> Can you push it to the github, please?

Good idea.

http://github.com/michelf/mfr-xml-d

Feel free to send pull requests if you want. I should be able to review them.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca