From: Mark A. F. <mar...@ea...> - 2004-04-16 21:08:49
|
>... ATTRIBUTES hash is checked only when you use UDDI >syntax ("foo->bar" or "foo with bar"); in all other cases (when you >use UDDI::Data or foo->attr({bar => 'foobar'})) ATTRIBUTES hash is >not used -- you should be allowed to set/get any attributes you like. You're right. The following accesses the "xml:lang" attribute: $name->{'_attr'}{'xml:lang'}; While we're on the subject of different syntaxes, you provided this example as a way to bypass ATTRIBUTES hash checking: foo->attr({bar => 'foobar'}) Is there a form that will return the value? I'm keeping all these examples and intend to work them into my samples of exercising v2. I guess the question now is, 1. UDDI:Lite limits its awareness to only attributes within the UDDI namespace? Users will have to be aware that they must use the format above to access attributes outside the namespace? 2. UDDI:Lite maintains non-uddi namespace in its ATTRIBUTES table? and the user access attributes as "foo->ns:bar" in those cases? (The interpreter doesn't like that syntax. We'd have to come up with another way of keeping namespace). 3. Since UDDI is a single namespace, can namespace be ignored? Could there be a collision of differently namespaced elements or attributes within the UDDI schema? I think this is an important question because v3 increases the use of "xml:lang". In v1 it may not have been important. It was used on only one element. For v2 it is used on two and is part of querying by name (specifying language to limit the query to). v3 increases it to 4 elements (address and personName). Mark ---- for my $name ($businessInfo->name) { print ' ' . $name . ' (' . $name->lang . ')' . "\n"; my $x = $name->{'_attr'}{'xml:lang'}; print 'here' . $x; } # end loop for name ---- |
From: Paul K. <pau...@ya...> - 2004-04-17 06:11:16
|
Mark, --- "Mark A. Fuller" <mar...@ea...> wrote: > You're right. The following accesses the "xml:lang" attribute: > > $name->{'_attr'}{'xml:lang'}; This code works, but shouldn't be used. See below. > While we're on the subject of different syntaxes, you provided this > example as a way to bypass ATTRIBUTES hash checking: > > foo->attr({bar => 'foobar'}) > > Is there a form that will return the value? I'm keeping all these > examples and intend to work them into my samples of exercising v2. There is. In fact, the code above is not the best way to do it as it sets 'bar' as the ONLY attribute effectively removing everything else. Here is the code that does what you need. foo->attr->{bar} = 'foobar'; # SET print foo->attr->{bar}; # GET > 1. UDDI:Lite limits its awareness to only attributes within the > UDDI namespace? Users will have to be aware that they must use the > format above to access attributes outside the namespace? Yes. No. Below. > 2. UDDI:Lite maintains non-uddi namespace in its ATTRIBUTES table? > and the user access attributes as "foo->ns:bar" in those cases? > (The interpreter doesn't like that syntax. We'd have to come up > with another way of keeping namespace). This syntax won't work. I suggest we keep everything as it is (ALL attributes in one table) and add one more table for namespaces. Those attributes that are not in UDDI namespace will (also) be represented there. Code that generates attributes will be smart to look at that table. That won't work if there are two element in different namespaces with the same name, but that's not the sace with existing UDDI specs as far as I know. > 3. Since UDDI is a single namespace, can namespace be ignored? > Could there be a collision of differently namespaced elements or > attributes within the UDDI schema? No; you still need to generate proper namespaces, or server will reject your request. Unlikely. > I think this is an important question because v3 increases the use > of "xml:lang". In v1 it may not have been important. It was used on > only one element. For v2 it is used on two and is part of querying > by name (specifying language to limit the query to). v3 increases > it to 4 elements (address and personName). Agreed. I uploaded a new version that includes elements and attributes for UDDIv2 and UDDIv3 you provided. I also fixed NAMESPACES/GENERIC for UDDIv2 and v3. Next step is to figure out what todo for attributes in non-UDDI namespace. I'll check if my idea works. Best wishes, Paul. |
From: Mark F. <mar...@ea...> - 2004-04-17 19:37:16
|
Hi Paul, I have written a script to call each v2 inquiry API service and display each element/attribute of each result. Everything works great! I'd like to contribute that inquiry script as a sample. The existing samples demonstrate this. But, this one demonstrates each service and every result. More verbose too. (I started programming in COBOL. Everythign I do looks like COBOL <ha>). I'll send it to you in a few days. Regarding the non-uddi namespace attributes (xml:lang in all three versions) and elements (dsig:Signiture in v3), I discovered something else in v2 which may affect how you plan to handle this. In v2 the method "get_businessDetailExt" which returns a "businessEntityExt". This element contains a "businessEntity" element and this: <xsd:any namespace="##other" processContents="strict" minOccurs="0" maxOccurs="unbounded" /> I don't know if this is something you want to program for and/or how much it overlaps the issue of non-uddi namespace elements and attribues used in the UDDI schema. At a minimum it will have to be documented that the user use a special syntax to access non-uddi namespace elements and attributes unknown to the UDDI schema. ("foo->attr->{'ns:bar'}" for the attribute. How would the element be accessed?) You could apply the same rule to non-uddi namespace elements and attributes used in the UDDI schema. Conversely, whatever you program for in the case of non-uddi namespace elements and attributes used in the UDDI schema, could it be made more flexible and capable of being extended in cases that a user is processing results that are defined by a schema unknown to UDDI? (That's why it seems like there's a slight amount of overlap between both issues.) Thanks, Mark |
From: Mark F. <mar...@ea...> - 2004-04-18 05:01:54
|
Hi Paul, A quick question. I hope this isn't something that belongs on the user list. It's part of my attempt to contribute a v2 sample which calls each service and processes the entire result of each. I have the latter half complete and am working on making the "calls" a better example. I want to dynamically build the parms (or content model?) to a UDDI method based upon whether optional elements (and attributes) are present. The sample/syntax1 script gave me ideas. Using "find_binding" as an example, I came up with this: ======= start ======= #---------------------- # If findQualifier values were specified, create the UDDI::Lite structure # and add it to the array of objects to be passed to find_binding. #------------------------------- if (defined($findQualifier)) { $find_binding[$#find_binding + 1] = findQualifiers( findQualifier(@{$findQualifier}) ); } #---------------------- # tModelBag is always required. Build the structure and add # it to the array of objects to be passed to find_binding. #---------------------- $find_binding[$#find_binding + 1] = tModelBag( tModelKey(@{$tModelKeys}) ); $bindingDetail = find_binding({serviceKey => $serviceKey, maxRows => $maxRows}, @find_binding); ======= end ======= Two questions: 1. The above works. Is there a better way to accumulate optional and required elements and attributes based upon dynamic input to a script (example, from a web page)? 2. How can I dynamically add attributes to find_binding? For example, let's say serviceKey and maxRows are both optional. How can I include them depending upon their presence? I can't do "find_binding->attr->maxRows{maxRows} = $maxRows". It causes find_binding to be executed as a method. Thanks! Mark |
From: Paul K. <pau...@ya...> - 2004-04-18 06:31:06
|
Mark, > if (defined($findQualifier)) { > $find_binding[$#find_binding + 1] = > findQualifiers( > findQualifier(@{$findQualifier}) > ); > } can also be written as: push @params, findQualifiers(findQualifier(@$findQUalifier)) if ref $findQualifier; > $find_binding[$#find_binding + 1] = > tModelBag( > tModelKey(@{$tModelKeys}) > ); push @params, tModelBag(tModelKey(@$tModelKeys)) if ref $tModelKeys; > 2. How can I dynamically add attributes to find_binding? For Just create a hash with those parameters and set only ones you need: $attrs{maxRows} = 5; # and later: $bindingDetail = find_binding($attrs, @parameters); Hope that works for you. Paul. --- Mark Fuller <mar...@ea...> wrote: > Hi Paul, > > A quick question. I hope this isn't something that belongs on the > user list. > It's part of my attempt to contribute a v2 sample which calls each > service > and processes the entire result of each. I have the latter half > complete and > am working on making the "calls" a better example. > > I want to dynamically build the parms (or content model?) to a UDDI > method > based upon whether optional elements (and attributes) are present. > The > sample/syntax1 script gave me ideas. Using "find_binding" as an > example, I > came up with this: > > ======= start ======= > #---------------------- > # If findQualifier values were specified, create the UDDI::Lite > structure > # and add it to the array of objects to be passed to find_binding. > #------------------------------- > if (defined($findQualifier)) { > $find_binding[$#find_binding + 1] = > findQualifiers( > findQualifier(@{$findQualifier}) > ); > } > > #---------------------- > # tModelBag is always required. Build the structure and add > # it to the array of objects to be passed to find_binding. > #---------------------- > $find_binding[$#find_binding + 1] = > tModelBag( > tModelKey(@{$tModelKeys}) > ); > > $bindingDetail = find_binding({serviceKey => $serviceKey, maxRows > => > $maxRows}, > @find_binding); > > ======= end ======= > > Two questions: > > 1. The above works. Is there a better way to accumulate optional > and > required elements and attributes based upon dynamic input to a > script > (example, from a web page)? > > 2. How can I dynamically add attributes to find_binding? For > example, let's > say serviceKey and maxRows are both optional. How can I include > them > depending upon their presence? I can't do > "find_binding->attr->maxRows{maxRows} = $maxRows". It causes > find_binding to > be executed as a method. > > Thanks! > 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 |
From: Mark F. <mar...@ea...> - 2004-04-19 02:50:28
Attachments:
inquirev2
|
From: "Paul Kulchenko" <pau...@ya...> > Just create a hash with those parameters and set only ones you need: Hi Paul, I appreciate your prompt responses. It has helped me test UDDI v2 quickly. I've executed all the inquiry methods and processed every element and attribute. It works fine. The only issue is "lang" namespaced to "xml" (and, in v3, the element "Signiture" namespaced to "dsig"). And the v2 "find_businessExt" method which provides for unknown schemas in the result. There could be some crossover between this and the attributes and elements in the UDDI schema namespaced elsewhere. I've attached the script I used to test all the v2 inquiry services. If you would like to add it to the "samples" I would appreciate it. Something like this would have helped me get up to speed with UDDI::Lite. I think it will be useful to others. If you see any glaring mistakes, or alternative ways to do things, you're welcome to change the script. I'd like to update the POD for UDDI::Lite and make it easier to comprehend (from my "newbie" perspective). But, there's so many ways to invokeUDDI::Lite functions that I'm not sure I can improve on the POD. As a newbie, I wish it would have been simpler and more straightforward. From what I know, I think I could improve upon the POD. But, I'm worried about the things I don't know. :) Do you think it might be better to have a single syntax rather than so many alternatives? I'll test v3 in a month when I have a v3 server. I'd like to create a v3inquire script similiar to v2inquire. Thanks, Mark |
From: Mark F. <mar...@ea...> - 2004-04-20 05:51:08
|
Paul, I'm testing the publishing part of UDDI::Lite. I can obtain an "authInfo" using this: =========================== $attrs{userID} = 'admin'; $attrs{cred} = 'changeit'; $authToken = get_authToken(\%attrs); my $authInfo = $authToken->authInfo; ============================== However, I can't seem to use $authInfo on subsequent calls which require it. For example: ====================== push @params, authInfo($authInfo); <== This is line 155 my $publisherAssertions = get_publisherAssertions(@params); Don't know what to do with 'authInfo' and 'authInfo' elements at publishv2 line 155 ====================== If I try to pass it as a parm to "get_publisherAssertions" ==================== my $publisherAssertions = get_publisherAssertions($authInfo); ==================== It generates the "authinfo" element as prefixed with "namesp1:". I thought this syntax is equivalent to the example "publish1.pl". Am I doing something wrong? Thanks Mark |