OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] URI Design

[ Lists Home | Date Index | Thread Index ]

* 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:




    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 &lt;strong&gt;love&lt;/strong&gt; 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 - alan@engrm.com
    - http://engrm.com/blogometer/index.html
    - http://engrm.com/blogometer/rss.2.0.xml


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS