• Brad Anderson (6/6) Aug 11 2003 I saw some older posts about some efforts to make a pure D XML parser or...
• Brad Anderson (3/12) Aug 11 2003 I was able to get Andy's page to come up:
• Benji Smith (11/17) Aug 12 2003 I'm very close to being finished with it. The actual parser is done, but...
• Brad Anderson (11/40) Aug 15 2003 Benji,
• Benji Smith (14/17) Aug 15 2003 It will be DOM-like, though it will not exactly comply with the DOM inte...
• Brad Anderson (2/29) Aug 17 2003
• Matthew Wilson (9/38) Aug 18 2003 No, but that sounds like a non-too-hard task. A good place to start, per...
• Matthew Wilson (12/29) Aug 18 2003 It's probably way too late, but I would have thought it sensible to crea...
• Benji Smith (16/21) Aug 19 2003 The reason I didn't start with a SAX parser is because I'm not very fami...

Brad Anderson <brad sankaty.com> writes:

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 <brad sankaty.com> writes:

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

Benji Smith <dlanguage xxagg.com> writes:

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

Brad Anderson <brad sankaty.com> writes:

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

Benji Smith <dlanguage xxagg.com> writes:

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

Brad Anderson <brad sankaty.com> writes:

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
 
 

"Matthew Wilson" <matthew stlsoft.org> writes:

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

"Matthew Wilson" <matthew stlsoft.org> writes:

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

Benji Smith <dlanguage xxagg.com> writes:

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?