Re: Perl and *ML
Dan Sugalski wrote: I think that the issue here isn't so much good perl support for XML as it is good support for attributed DAGs, something which would be of general good use for perl, since the ASTs the parser feeds to the compiler will ultimately be DAGs of a sort. So, rather than jumping on the XML [insert verb here]! bandwagon, perhaps we'd be better served figuring out what would be useful operations and support for/on DAGs and suchlike things? Fast and efficient graphs of all sorts would be very useful. A way to define a complex graph of interlinked arbitrary objects while being reasonable on memory and good with GC would be a definitive big win, especially if it can be lazy. Especially with nice ways to write visitors and easy searches in the graph based on object properties (but I could be asking for too much ;). DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Some automata can treat a stream of events as a B-Tree being visited, but those are rather rare currently. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
On Mar 26, Robin Berjon wrote: Dan Sugalski wrote: I think that the issue here isn't so much good perl support for XML as it is good support for attributed DAGs, something which would be of general good use for perl, since the ASTs the parser feeds to the compiler will ultimately be DAGs of a sort. ++good So, rather than jumping on the XML [insert verb here]! bandwagon, perhaps we'd be better served figuring out what would be useful operations and support for/on DAGs and suchlike things? Fast and efficient graphs of all sorts would be very useful. A way to define a complex graph of interlinked arbitrary objects while being reasonable on memory and good with GC would be a definitive big win, especially if it can be lazy. Especially with nice ways to write visitors and easy searches in the graph based on object properties (but I could be asking for too much ;). DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Pardon me? Could you please provide an example? - Kurt
Re: Perl and *ML
At 4:47 PM +0100 3/26/03, Robin Berjon wrote: Dan Sugalski wrote: I think that the issue here isn't so much good perl support for XML as it is good support for attributed DAGs, something which would be of general good use for perl, since the ASTs the parser feeds to the compiler will ultimately be DAGs of a sort. So, rather than jumping on the XML [insert verb here]! bandwagon, perhaps we'd be better served figuring out what would be useful operations and support for/on DAGs and suchlike things? Fast and efficient graphs of all sorts would be very useful. A way to define a complex graph of interlinked arbitrary objects while being reasonable on memory and good with GC would be a definitive big win, especially if it can be lazy. Especially with nice ways to write visitors and easy searches in the graph based on object properties (but I could be asking for too much ;). Probably a bit much, yep. :) I'd be happy with simple graph representation, annotation, and traversal. And for my purposes a DAG is sufficient. Loops are terribly annoying to have to deal with. DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Some automata can treat a stream of events as a B-Tree being visited, but those are rather rare currently. I was under the impression XML was very much a tree, and didn't do loops. Am I missing something here? (I don't, in general, do XML) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl and *ML
Dan Sugalski wrote: At 4:47 PM +0100 3/26/03, Robin Berjon wrote: Fast and efficient graphs of all sorts would be very useful. A way to define a complex graph of interlinked arbitrary objects while being reasonable on memory and good with GC would be a definitive big win, especially if it can be lazy. Especially with nice ways to write visitors and easy searches in the graph based on object properties (but I could be asking for too much ;). Probably a bit much, yep. :) I'd be happy with simple graph representation, annotation, and traversal. And for my purposes a DAG is sufficient. Loops are terribly annoying to have to deal with. Efficient annotation and traversal would go a long way, but almost all useful XML representations have loops unfortunately. DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Some automata can treat a stream of events as a B-Tree being visited, but those are rather rare currently. I was under the impression XML was very much a tree, and didn't do loops. Am I missing something here? (I don't, in general, do XML) Your impression isn't wrong, it's just that in actual use one needs more information. If you lose the cycles then you could as well just be working on stream of parse events (which is typical in SAX), in which case an in-memory representation is probably not useful. And that's just for basic stuff, if you want to usefully represent ID/IDREFs, QName linking, internal XLinks, etc you're basically pointing from random nodes to other random nodes. Given what you describe plus loops we could take over and do Really Cool Stuff :) -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
On Wed, Mar 26, 2003 at 05:40:56PM +0100, Robin Berjon wrote: Dan Sugalski wrote: At 4:47 PM +0100 3/26/03, Robin Berjon wrote: Fast and efficient graphs of all sorts would be very useful. A way to define a complex graph of interlinked arbitrary objects while being reasonable on memory and good with GC would be a definitive big win, especially if it can be lazy. Especially with nice ways to write visitors and easy searches in the graph based on object properties (but I could be asking for too much ;). Probably a bit much, yep. :) I'd be happy with simple graph representation, annotation, and traversal. And for my purposes a DAG is sufficient. Loops are terribly annoying to have to deal with. Efficient annotation and traversal would go a long way, but almost all useful XML representations have loops unfortunately. DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Some automata can treat a stream of events as a B-Tree being visited, but those are rather rare currently. I was under the impression XML was very much a tree, and didn't do loops. Am I missing something here? (I don't, in general, do XML) By loop you mean attributes declared by DTD as IDREFs and pointing to element having the same value for the attribut ID? Like in the example pasted from XML in a nutshell? project project_id=p1 goalDevelop Strategic Plan/goal team_member person=ss078-05-1120/ team_member person=ss987-65-4320/ /project project project_id=p2 goalDeploy Linux/goal team_member person=ss078-05-1120/ team_member person=ss9876-12-3456/ /project employee social_security_label=ss078-05-1120 nameFred Smith/name assignment project_id=p1/ assignment project_id=p2/ /employee employee social_security_label=ss987-65-4320 nameJill Jones/name assignment project_id=p1/ /employee employee social_security_label=ss9876-12-3456 nameSydney Lee/name assignment project_id=p2/ /employee In a way IDREF are similar to symlinks? they cannot create real loops because they are not followed by default by traversal tool juste like find does not follow symlinks by default. -- stef Your impression isn't wrong, it's just that in actual use one needs more information. If you lose the cycles then you could as well just be working on stream of parse events (which is typical in SAX), in which case an in-memory representation is probably not useful. And that's just for basic stuff, if you want to usefully represent ID/IDREFs, QName linking, internal XLinks, etc you're basically pointing from random nodes to other random nodes. Given what you describe plus loops we could take over and do Really Cool Stuff :) -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
Stéphane Payrard wrote: On Wed, Mar 26, 2003 at 05:40:56PM +0100, Robin Berjon wrote: Efficient annotation and traversal would go a long way, but almost all useful XML representations have loops unfortunately. By loop you mean attributes declared by DTD as IDREFs and pointing to element having the same value for the attribut ID? In a way IDREF are similar to symlinks? they cannot create real loops because they are not followed by default by traversal tool juste like find does not follow symlinks by default. Part of the problem doesn't involve referencing. Practically all XML representations will have at the very least children pointing back to their parents, and probably more than just that. Another part of the problem is that, indeed IDREFs, QName links, internal XLinks, or other referencing approaches can be treated as symlinks and in fact more or less currently are. However that's often suboptimal/inefficient to implement because either you point to the target (in which case you have a cycle) or you have to look for it. If we want to make things better than they are currently, that kind of loop needs to be simple and efficient. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: Perl and *ML
Kurt Starsinic wrote: On Mar 26, Robin Berjon wrote: DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Pardon me? Could you please provide an example? XML per se, using an impoverished Information Set (no IDs) can be considered to be a tree, which would naturally make it a DAG. However that's pretty much an abstract representation that is rarely of much use in actual XML programming. In your typical DOM, children point to their parent, siblings point to each other, everything points back to the root document, attributes point to their owner element, etc. Even if you remove some of those that are infrequently used, you can't remove all the cycles (or absences of direction as you may wish to see it) and have something useful. It gets worse with linking. -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
