[Soaplite-devel] UDDI attribute support

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

>... 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
----