[
Lists Home |
Date Index |
Thread 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 <alan-xml-dev@engrm.com> wrote:
> * M. David Peterson <m.david.x2x2x@gmail.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:
>
> <request>
> <server-name>engrm.com</server-name>
> <server-port>80</server-port>
> <content-type>application/x-www-form-url-encoded</content-type>
> <content-uri>request:content</content-type>
> </request>
>
> Using:
>
> request:properties
>
> Then I can create a varsity generated relay that looks like this:
>
> <relay>
> <stream>
> <uri>request:content</uri>
> </stream>
> <form-decode/>
> <saxon>
> <url>xslt/post-to-sql.xslt</url>
> </saxon>
> <sql>
> <connent-uri>jdbc:mysql:foo</connect-uri>
> </sql>
> </relay>
>
> (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:
>
> <form>
> <field>
> <name>first-name</name>
> <value>Alan</value>
> <uri>request:field:first-name:1</uri>
> </field>
> <field>
> <name>last-name</name>
> <value>Gutierrez</value>
> <uri>request:field:last-name:1</uri>
> </field>
> <field>
> <name>favorite-os</name>
> <value>Linux</value>
> <uri>request:field:favorite-os:1</uri>
> </field>
> <field>
> <name>favorite-os</name>
> <value>OS X</value>
> <uri>request:field:favorite-os:2</uri>
> </field>
> <field>
> <name>favorite-os</name>
> <value>OS/360</value>
> <uri>request:field:favorite-os:3</uri>
> </field>
> <field>
> <name>comments</name>
> <value>I <strong>love</strong> your software.</value>
> <uri>request:field:comments:1</uri>
> </field>
> </form>
>
> If there was a file upload field, I'd use a different parser,
> but the output would be very similar.
>
> <form>
> <field>
> <name>nickname</name>
> <value>Alan</value>
> <uri>request:field:nickname:1</uri>
> </field>
> <field>
> <name>photo</name>
> <content-type>image/jpg</content-type>
> <content-length>123456</content-length>
> <uri>file:///tmp/upload-213131.jpg</uri>
> </field>
> </form>
>
> 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:
>
> <relay>
> <stream>
> <uri>request:field:comments:1</uri>
> </stream>
> <html-tidy/>
> <saxon>
> <uri>xslt/strip-user-comment-html.xslt</uri>
> </saxon>
> </relay>
>
> I'm thinking hard about URI design because I'd probably pull
> that pipeline into a query using an include:
>
> <xsl:value-of
> select="document('varisty:/internal/user-comments.xml')/xhtml:html"/>
>
> 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
> valid.
>
> 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.
>
> Cheers.
>
> --
> Alan Gutierrez - alan@engrm.com
> - http://engrm.com/blogometer/index.html
> - http://engrm.com/blogometer/rss.2.0.xml
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
