www.digitalmars.com         C & C++   DMDScript  

D - XML API for D

reply 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
Aug 11 2003
next sibling parent 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
Aug 11 2003
prev sibling parent reply 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

Aug 12 2003
parent reply 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
Aug 15 2003
parent reply 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
Aug 15 2003
next sibling parent reply 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

Aug 17 2003
parent "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


 (which I think is a little bulky). For example, DOM specifies that


 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


 with a document at the top. There are no events (like SAX). The only


 created a DOM parser is that I tend to use DOM much more often than I


 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


 SAX-based twin-sister.

 --Benji Smith


Aug 18 2003
prev sibling parent reply "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

 (which I think is a little bulky). For example, DOM specifies that

 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

 with a document at the top. There are no events (like SAX). The only

 created a DOM parser is that I tend to use DOM much more often than I use

 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

Aug 18 2003
parent 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?

Aug 19 2003