Lists Home |
Date Index |
Yeah, after reading this I was definitely thinking very broadly,
answering more to the question of, in essence, just how important or
powerful using highly structured XML was, but focusing on a very
general perspective instead of specific to what you are trying to
accomplish. No worries, maybe it will be useful to someone else later
on down the road instead ;)
On 4/21/05, Alan Gutierrez <firstname.lastname@example.org> wrote:
> * M. David Peterson <email@example.com> [2005-04-21 12:03]:
> > Hey, this is pretty cool. In my opinion and in answer to your
> > hierarchical question the time to use a generalogical structure as
> > part of your XML-based language is if you plan to use these
> > relationsips as a way of enforcing an implied set of logical
> > processing rules. For example, if there is no child element "doThis"
> > then obviously this method is not available for that portion of your
> > code base... quick and dirty error checking. You can also make nested
> > structure that will step through to each child element until it
> > evaluates to true (based on whatever you are testing for. e.g. using
> > the value of the data and the name() or local-name() of the element
> > to determine the name of a sequence that should then be invoked to
> > properly the child elements of the parents name value being tested.
> Okay, I'm falling behind on the lingo, as I usally do in this
> mailing list. I'm looking at creating a simple document thus:
> Let's use a custom scheme specific part to remove any implied
> hieracrchy. Let's say I filled out a form like so:
> First Name: Alan
> Last Name: Gutierrez
> Farvorite OS:
> Linux [x] OS X [z] Palm OS [ ] Windows 98 [ ] OS/360 [x] Other[ ]
> Comments: I <strong>love</strong> your software.
> In Relay I can fetch this document:
> Then I can create a varsity generated relay that looks like this:
> (The SQL bit is totally, naive, yes. I've put more work into XML
> to relational mapping than the example above.)
> In any case, the form-decode element creates a document that
> looks like this:
> <value>OS X</value>
> <value>I <strong>love</strong> your software.</value>
> If there was a file upload field, I'd use a different parser,
> but the output would be very similar.
> Note how the photo URI is swapped out with a file URL. My
> chioces might seem more reasonable.
> Taking the first example, I could create a pipeline like so:
> I'm thinking hard about URI design because I'd probably pull
> that pipeline into a query using an include:
> That would fire the parse and clean comments pipeline. The
> heirarchy comes back into play, since a Varisty URI is supposed
> to be interchangable with a file or http URI.
> > An example of each of the XML trees for something like this might look
> > like:
> > Data being processed:
> > <foo>
> > <bar>
> > <element>data</element>
> > <element>data</element>
> > </bar>
> > </foo>
> > Data its being compared against:
> > <foo true-sequence="seq1">
> > <bar true-sequence="seq2"/>
> > </foo>
> > Sequence definition file:
> > <sequence id="seq1">
> > <do_this/>
> > <then_this/>
> > <if_this>
> > <do_this/>
> > </if_this>
> > </sequence>
> > Using this type of dynamic application construction can be really
> > powerful and as long as you seperate the XML definition files out into
> > seperate files, allowing only elements and data that are there serving
> > the same purpose (e.g. to invoke a processing sequence) then I think
> > you will find this a simple way to maintain decent code readability as
> > well as the ability to use the structure viewing tools contained
> > within the tools we use an extremely powerful way to view whats taking
> > place in your code without having to scan a 2000 line file up and down
> > looking for this sequence or that sequence, etc...
> > I really like your chosen style. I would be interested in seeing how
> > this continues to develop for my own learning so please keep us up to
> > date, or if you would prefer, just those of us who want to watch by
> > creating an Atom feed that we can subscribe to.
> > Cheers :)
> Again, trying to keep up with the nomeclature, but I think you
> are thinking a head of me.
> Relay/Varisty to a bang up job of creating a new XML document
> from sundry sources. It's simply because all the data flows into
> one document.
> Handling a form submission is difficult, becasue you need to
> branch the pipeline, different output if the submission is not
> Furthermore, it is a realy pain to deal with a form submission
> that goes to multiple destinations, say an LDAP DB, an RDB, an
> XMLDB, a web service, an e-mail notification, etc.
> I'm thinking about a new set of problems, including
> multiplexing and transactions on the inbound, while I already
> feel confident in my strategies for caching, dependencies, and
> aggregation on the outbound.
> If you are talking about abstracting business logic, then I'm
> not doing that quite yet. I'm simply generating pipelines using
> XSLT, so much of the application logic is in (oh, my) XSLT 2.0.
> However, if you can express your business logic ultimately as
> XML pipelines, and initially create a document that can be
> transformed into those pipelines, then Relay/Varsity is probably
> the output format. Relay/Varsity does not include any logic,
> merely a caching engine. Logic is supposed to be external, and
> Relay/Varsity are supposed to snap to it, parse an XML pipeline
> specification, and execute it a quickly as possible.
> I hope this helps. It's all open source, as I noted before. If
> you're interested let me know. The RSS feed is below.
> Alan Gutierrez - firstname.lastname@example.org
> - http://engrm.com/blogometer/index.html
> - http://engrm.com/blogometer/rss.2.0.xml
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist