I saw some older posts about some efforts to make a pure D XML parser or API (Matthew Wilson, 3/24/03) and wondered if there were any updates. Benji Smith was doing some work w/o DTD support, as well as Andy Friesen.

I am willing to test, if someone has an API to use.

Thanks,
Brad

Brad Anderson wrote:
> I saw some older posts about some efforts to make a pure D XML parser or API (Matthew Wilson, 3/24/03) and wondered if there were any updates. Benji Smith was doing some work w/o DTD support, as well as Andy Friesen.
> 
> I am willing to test, if someone has an API to use.
> 
> Thanks,
> Brad
> 

I was able to get Andy's page to come up:

http://www.ikagames.com/andy/d/xmld.zip

I'm very close to being finished with it. The actual parser is done, but I'm still not happy with my node classes. I'm using linked lists for element nodes, but I'm having trouble designing a linked list template/class that fits my needs. The current state-of-affairs with D templates is preventing me from implementing my ideal design, so I'm mulling around trying to decide how else to implement them.

By the way, if anyone has a linked list template that they're happy with, let me know, and I might be able to speed up development of my xml api by using it.

Thanks,

--Benji Smith


In article <bh95pc$27cc$1@digitaldaemon.com>, Brad Anderson says...
>
>I saw some older posts about some efforts to make a pure D XML parser or API (Matthew Wilson, 3/24/03) and wondered if there were any updates. Benji Smith was doing some work w/o DTD support, as well as Andy Friesen.
>
>I am willing to test, if someone has an API to use.
>
>Thanks,
>Brad
>

Benji Smith wrote:
> I'm very close to being finished with it. The actual parser is done, but I'm
> still not happy with my node classes. I'm using linked lists for element nodes,
> but I'm having trouble designing a linked list template/class that fits my
> needs. The current state-of-affairs with D templates is preventing me from
> implementing my ideal design, so I'm mulling around trying to decide how else to
> implement them.
> 
> By the way, if anyone has a linked list template that they're happy with, let me
> know, and I might be able to speed up development of my xml api by using it.
> 
> Thanks,
> 
> --Benji Smith
> 
> 
> In article <bh95pc$27cc$1@digitaldaemon.com>, Brad Anderson says...
> 
>>I saw some older posts about some efforts to make a pure D XML parser or API (Matthew Wilson, 3/24/03) and wondered if there were any updates. Benji Smith was doing some work w/o DTD support, as well as Andy Friesen.
>>
>>I am willing to test, if someone has an API to use.
>>
>>Thanks,
>>Brad
>>
> 
> 
> 

Benji,

I've been tracking some of your other posts (Method Blocking, Mixins, Template Wishlist), and I see some of your XML work in there.  I'm wondering if your API/parser will be DOM-like or SAX-like or both.

If the question doesn't make sense, forgive me.  I'm a bit of a newbie, and I'm trying to make my way into serious programming with templates/generics, linked lists, and all that.  But I have a couple of XML tasks to knock out first, and even that part (API's, parsers) is new...

Thanks,
Brad

In article <bhj4gn$2v8n$1@digitaldaemon.com>, Brad Anderson says...
>I've been tracking some of your other posts (Method Blocking, Mixins, Template Wishlist), and I see some of your XML work in there.  I'm wondering if your API/parser will be DOM-like or SAX-like or both.

It will be DOM-like, though it will not exactly comply with the DOM interface (which I think is a little bulky). For example, DOM specifies that attributes should be objects. I'd rather have an associative array called...

char[][char[]] attributes;

..which would make it easy to access attributes, like this:

attribute[]["attrib_name"];

But, for the most part, the API looks like DOM. It's a nested tree structure, with a document at the top. There are no events (like SAX). The only reason I created a DOM parser is that I tend to use DOM much more often than I use SAX, though I could see how a SAX parser would be more appropriate for some situations. Maybe after I finish the DOM version, I'll modify it to have a SAX-based twin-sister.

--Benji Smith

Has anyone ever wrapped the C Expat parser (expat.h) in D ??





Benji Smith wrote:
> In article <bhj4gn$2v8n$1@digitaldaemon.com>, Brad Anderson says...
> 
>>I've been tracking some of your other posts (Method Blocking, Mixins, Template Wishlist), and I see some of your XML work in there.  I'm wondering if your API/parser will be DOM-like or SAX-like or both.
> 
> 
> It will be DOM-like, though it will not exactly comply with the DOM interface
> (which I think is a little bulky). For example, DOM specifies that attributes
> should be objects. I'd rather have an associative array called...
> 
> char[][char[]] attributes;
> 
> ..which would make it easy to access attributes, like this:
> 
> attribute[]["attrib_name"];
> 
> But, for the most part, the API looks like DOM. It's a nested tree structure,
> with a document at the top. There are no events (like SAX). The only reason I
> created a DOM parser is that I tend to use DOM much more often than I use SAX,
> though I could see how a SAX parser would be more appropriate for some
> situations. Maybe after I finish the DOM version, I'll modify it to have a
> SAX-based twin-sister.
> 
> --Benji Smith
> 
> 

It's probably way too late, but I would have thought it sensible to create the SAX parser first, and then implement the DOM parser in terms of the SAX. This would be easier (you only have to do your syntax parsing once), as well as killing two birds with one stone.

Too late to change?

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:bhj5ae$2vsu$1@digitaldaemon.com...
> In article <bhj4gn$2v8n$1@digitaldaemon.com>, Brad Anderson says...
> >I've been tracking some of your other posts (Method Blocking, Mixins, Template Wishlist), and I see some of your XML work in there.  I'm wondering if your API/parser will be DOM-like or SAX-like or both.
>
> It will be DOM-like, though it will not exactly comply with the DOM
interface
> (which I think is a little bulky). For example, DOM specifies that
attributes
> should be objects. I'd rather have an associative array called...
>
> char[][char[]] attributes;
>
> ..which would make it easy to access attributes, like this:
>
> attribute[]["attrib_name"];
>
> But, for the most part, the API looks like DOM. It's a nested tree
structure,
> with a document at the top. There are no events (like SAX). The only
reason I
> created a DOM parser is that I tend to use DOM much more often than I use
SAX,
> though I could see how a SAX parser would be more appropriate for some situations. Maybe after I finish the DOM version, I'll modify it to have a SAX-based twin-sister.
>
> --Benji Smith
>
>

No, but that sounds like a non-too-hard task. A good place to start, perhaps

"Brad Anderson" <brad@sankaty.com> wrote in message news:bhpca4$1n5g$1@digitaldaemon.com...
> Has anyone ever wrapped the C Expat parser (expat.h) in D ??
>
>
>
>
>
> Benji Smith wrote:
> > In article <bhj4gn$2v8n$1@digitaldaemon.com>, Brad Anderson says...
> >
> >>I've been tracking some of your other posts (Method Blocking, Mixins, Template Wishlist), and I see some of your XML work in there.  I'm wondering if your API/parser will be DOM-like or SAX-like or both.
> >
> >
> > It will be DOM-like, though it will not exactly comply with the DOM
interface
> > (which I think is a little bulky). For example, DOM specifies that
attributes
> > should be objects. I'd rather have an associative array called...
> >
> > char[][char[]] attributes;
> >
> > ..which would make it easy to access attributes, like this:
> >
> > attribute[]["attrib_name"];
> >
> > But, for the most part, the API looks like DOM. It's a nested tree
structure,
> > with a document at the top. There are no events (like SAX). The only
reason I
> > created a DOM parser is that I tend to use DOM much more often than I
use SAX,
> > though I could see how a SAX parser would be more appropriate for some situations. Maybe after I finish the DOM version, I'll modify it to have
a
> > SAX-based twin-sister.
> >
> > --Benji Smith
> >
> >
>

The reason I didn't start with a SAX parser is because I'm not very familiar with them. I understand the idea of event firing for various types of nodes in the document, but I haven't ever worked with a SAX parser, so I'm not intimitely familiar with the API. On the other hand, I've worked with DOM parsers quite a bit, and I'm pretty confident that I know the standard API well enough to know how it can be implemented in D. Also, I have enough opinions about the DOM standard to know where I want to stick with the standard and where I'd prefer to deviate from the standard a little. With SAX, I don't have enough knowledge to form any such opinions.

Having said all of that, though, I think it will be pretty trivial to retrofit a SAX parser into the existing DOM parser. I'll have to do some reading up on SAX, though, so it'll have to wait until later. Plus, I'd like to make sure that I have a stable DOM API before I start tankering with the parser to add SAX capabilities.

--Benji Smith

In article <bhrgkt$1rnm$1@digitaldaemon.com>, Matthew Wilson says...
>
>It's probably way too late, but I would have thought it sensible to create the SAX parser first, and then implement the DOM parser in terms of the SAX. This would be easier (you only have to do your syntax parsing once), as well as killing two birds with one stone.
>
>Too late to change?