I too have a major problem with HTML and XML heirarchical structure - it's not the way most things work.
What we are doing is cramming arbitarily-structured information into a predefined heirarchy. What we should be doing is assigning appropriate structures to the information as required by (a) the intrinsic structure of the content, (b) the relationship between the information and the application, and ((c) the structure of the application itself. All 3 are different and should be separable, and NONE of them are always heirarchical. Kemp > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Robert M. Muench > Sent: October 11, 2002 10:24 AM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: XML.com Embedded Markup Considered Harmful [Oct. > 02, 1997] > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > On Behalf Of Andrew Martin > > Sent: Friday, October 11, 2002 6:36 AM > > To: [EMAIL PROTECTED] > > Subject: [REBOL] Re: XML.com Embedded Markup Considered > > Harmful [Oct. 02, 1997] > > > It's got some demos; which are a _bit_ easier to understand. Don't ask > me; > > I'm still thinking about it! > > Hi, oh yes Ted Neslson's Xanadu stuff. Quite old but gives a good new > POV if you find a way through the web-site and document mess that won't > confuse you to much ;-). > > I'm thinking about this stuff and merging it into my rebol-framework > approach. It's not that hard as the idea is quite simple (at least what > I did understood so far): > > 1. You have a set of nodes (or cells) > 2. You have some qualified connections between nodes (all nodes that are > surnames are connected) > > Now you can view at your data a long a qualified connection line > (dimension): All surnames AS vertical ordered list. > > Walking through dimensions is most like traversing a graph only build > from a specific node type (all surname nodes). The idea is now not to > store the type of a node with the node-object (as I do it at the moment > too) but instead to specify the type of a node by including it into the > surname dimension. I like the idea because now a node can be part of > several dimensions. What's important is that we are talking about > navigation nodes (not mandatory data nodes). > > Why would you need this? > > You now could have the same node that is part of a project dimension, a > person dimension a rate dimension and a date dimension. The node would > have associated data-nodes for the different dimensions representing the > Bos. With the use of a navigation-node you now can create quite complex > queries like: give me all nodes that are part of the project, person, > rate and date dimension. If you have these nodes, you could create an > invoice from the data-nodes ;-). > > I hope you understand what I mean and I'm mostly sure it's not exactly > what zigzag offers but hey it's a first step. Robert > > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
