[
Lists Home |
Date Index |
Thread Index
]
Oh, in those sample XML sets the test would be to check for 'element'
children or possibly any child element that contains any number of
text() nodes to then evaluate to true, otherwise false and contiue to
step through if there are child elements to step through to.
On 4/21/05, M. David Peterson <m.david.x2x2x@gmail.com> wrote:
> 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.
> 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 :)
>
> On 4/21/05, Alan Gutierrez <alan-xml-dev@engrm.com> wrote:
> > I'm working on my XML pipeline engine, Relay. I'm using special
> > URIs to view information as documents. I'm creating a servlet,
> > for example, that explodes the HttpServletRequest into a
> > document, so I can bite into it with XSLT.
> >
> > <request>
> > <path-info>/foo/bar</path-info>
> > <server-name>engrm.com</server-name>
> > <content-type>application/x-www-form-urlencoded</content-type>
> > <content-uri>request://content/</content-uri>
> > </request>
> >
> > The above document is available from the URI:
> >
> > request://document/
> >
> > As you can see, I get the input as a stream using:
> >
> > request://content/
> >
> > I parse the content of the post in a Relay, and it makes each
> > form field avaialable as a stream, in case one of the fields is
> > really a hidden field with an JavaScript generated XML document in it.
> >
> > Or, else, I can run a textarea through HTML Tidy, to permit mild
> > markup in a comments box.
> >
> > That URI looks like:
> >
> > request://field/e-mail-address/1
> >
> > Which will return the first field named e-mail-address as a
> > stream.
> >
> > What do you all think? Am I designing these URIs correctly?
> >
> > Should I bother making them heirarcical? Or should I simply
> > create my own interpreation of the scheme specific part?
> >
> > request:document
> > request:content
> > request:field:e-mail-address[1]
> >
> > Thanks.
> >
> > --
> > Alan Gutierrez - alan@engrm.com
> > - http://engrm.com/blogometer/index.html
> > - http://engrm.com/blogometer/rss.2.0.xml
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> >
>
> --
> <M:D/>
>
> :: M. David Peterson ::
> XML & XML Transformations, C#, .NET, and Functional Languages Specialist
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|