RE: pointer to detailed metadata proposal

Steve,

1) SOAP Binding
	I am not sure if we can get away in SOAP-Binding without figuring
out what the extra transports addresses can be bound to SOAP. But I have to
wait until our implementers complain. Intuition says, there are going to be
issues in selecting the correct metadata to include in a SOAP envelope for a
any particular transport.

2) Adding New Element
	Metadata is too broad an element. In you really look at it
everything in this forum is metadata. Adding structure to the elements to
show the relationship between transport address and metadata is what I was
asking for. 

3) Reference vs. Value
By Garbage collection I meant on the SOAP processor or intermediary
processor the entity referred to has to be stored until time to live has
expired. That adds extra logic on the processors to do garbage collection.
If metadata is sent by value, the processors don't have to worry about it. 

Thanks,

Vikas

-----Original Message-----
From: Vinoski, Stephen [mailto:Steve.Vinoski@iona.com] 
Sent: Thursday, February 17, 2005 6:27 AM
To: vikasd@yahoo.com
Cc: public-ws-addressing@w3.org
Subject: RE: pointer to detailed metadata proposal

Vikas Deolaliker wrote:
> Where in the document does it cover changes to the
> SOAP-Binding document?

There are no changes to the SOAP binding. All of the metadata the proposal
deals with pertains to WSDL.

> Given the current structure of including all the transport
> end ports into
> the metadata element is confusing as a processor cannot
> unambiguously tell
> which port has what properties.

Not sure I follow. We're reusing existing WSDL elements to convey the
metadata, so they convey the same information that they convey for WSDL.

> Aren't we essentially trying to give a
> multichannel access to a back end service? If so, why not
> define an element
> called channel and include the port address and all meta data
> of that port
> into this element.

Actually, this proposal addresses both the issue of EPR metadata and
multichannel access.

The submitters did not want to invent alternative elements to contain
metadata when existing elements do just fine.

> Inclusion of metadata by reference for supposedly short lived
> EPR may need
> to be thought through. If metadata is dereferenceable then
> how do we do
> garbage collection in the processor? Allowing only by-value
> may solve this
> as the time-to-live for EPR will apply to the value as well.

Not sure what garbage you're talking about collecting -- can you explain? If
an EPR has a particular time-to-live, then any metadata reference it
contains is also subject to that time-to-live, and so is the metadata that
the metadata reference refers to, at least as far as fetching it via that
particular metadata reference is concerned.

--steve

Received on Friday, 18 February 2005 19:33:42 UTC