[plt-scheme] XML ease of use

I know this isn't too much help, but I avoid most of that in my own
programming by programming with xexprs most of the time and only using
the XML structs right before I print out the xml, or right after I
read it in.

Robby

On Tue, Aug 4, 2009 at 10:51 AM, Eddie Sullivan<eddieSull at hotmail.com> wrote:
> Hello.
> I've lately been having all kinds of frustrations making things work with
> the XML library. The biggest hurdle seems to be keeping track of all the
> types. We have "document" and "element" and "content" and "prolog" and
> "entity" and "pcdata" and so on and so forth. Every function seems to accept
> a different type.
>
> I think it would be helpful if there were some kind of abstract super-type
> for at least some of these things. Something similar to what the "content/c"
> contract checks for would be ideal, so that all those items could be treated
> the same until we wanted to differentiate them. Except I would think that
> "pcdata" and the like would be subtypes of "element."
>
> One other thing that bites me every time is that the "content" field of the
> "element" structure is actually specified by the contract (listof
> content/c). Either the name is wrong or the contract is.
>
> I don't know if self-referential contracts are possible, but it would be
> nice if content/c was really something like (or/c
> (current-definition-of-content/c) (listof content/c)). That's only one
> possible solution, though.
>
> The reason I don't like getting this (listof content/c) is that there is not
> much useful I can do with it. Since it doesn't satisfy content/c, I can't
> pass it to xml->xexpr or write-xml/content. Since it's not a document, I
> can't pass it to write-xml. I suppose I could do (apply string-append (map
> write-xml thing)), but that seems more involved than it has to be. If I
> could treat (listof content/c) the same as content/c that would go a long
> way towards making things easier.
>
> A form like "xml-match" would be very helpful, too, to avoid having to delve
> into the internals of the different xml structures.
>
> I think PLT Scheme's XML capabilities are very close to being the best thing
> out there, so I hope you take these as constructive suggestions.
> Thanks!
> -Eddie Sullivan
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>