Re: [Soaplite-devel] UDDI v2

[Mark F. <mar...@ea...>]

Paul,

I can manually add v2 to the list of elements and attributes where it
doesn't exist. (I wonder how many differences there are.) I

 was planning on writing my own UDDI module and add a "fetchInstance" method
to the SOAP::Lite result. This would unload UDDI's returned values to Perl
structures. This seemed simpler than working with xPath to navigate through
UDDI's result. It would encapsulate all the xPath navigation. But, after
processing some resulting Perl structures (arrays of arrays), it seems like
all I did was transfer the complexity of navigating xPath to the complexity
of nested array refs. :).

How does UDDI::Lite access results? The example in the POD shows:

===============================
  my $list = find_business(name => old);
  my $bis = $list->businessInfos;
  for ($bis->businessInfo) {
    my $s = $_->serviceInfos->serviceInfo;
    print $s->name,        # element
          $s->businessKey, # attribute
          "\n";
  }
===============================

How do those UDDI element names access the SOAP::Lite::SOM? Is this
something UDDI::Lite is doing? Or, is this functionality inherent to
SOAP::Lite::SOM?

Sorry if this is a question that should be on the user's list. My idea to
unload data to Perl structures was based upon xPath navigation being too
much work to repeat all the time. But, the above example form of access is
simple. I'm curious how that happens under the covers.

Thanks,
Mark


----- Original Message ----- 
From: "Paul Kulchenko" <pau...@ya...>
To: "Mark Fuller" <mar...@ea...>;
<soa...@li...>
Sent: Tuesday, April 13, 2004 11:12 PM
Subject: Re: [Soaplite-devel] UDDI v2


> Mark,
>
> From what I know about UDDIv2 it should be quite simple to make
> UDDI::Lite to support it. The key is in %elements and %attributes
> hashes (lines 50 and 51 in v0.60). They describe what combinations of
> elements and attributes are possible; everything else is sugar around
> it. I have a script that generates those hashes automatically from
> the UDDI schema. Unfortunately it doesn't work with v2 schema (I
> oversimplified the script a bit). It should not be difficult to
> update it or write a new one; it seems like there is nothing else
> that needs to be done. Also, we may add a parameter for 'use' and
> support both UDDI v1 and v2 in one module.
>
> Let me know if you need more details on how the module does its work.
>
> Paul
>
> --- Mark Fuller <mar...@ea...> wrote:
> > Before I get too far into my own UDDI implementation, I'd like to
> > know if
> > there is a way to make the existing UDDI::Lite accomodate UDDI v2,
> > or what
> > significant drawbacks you've found with it. I've looked at the code
> > and it's
> > so brief that I don't understand what it's doing or how. What I'm
> > working on
> > will be significantly larger -- but I'll understand it. :) However,
> > this
> > makes me wonder if I'm on the wrong track. Maybe I'm not taking
> > advantage of
> > something in SOAP::Lite the way the existing UDDI::Lite does?
> >
> > Mark
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO
> > of
> > GenToo technologies. Learn everything from fundamentals to system
> >
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Soaplite-devel mailing list
> > Soa...@li...
> > https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>