Hi Paul,
Paul said:
> I don't see how your sentence above has anything to do with my sentence
> above. Given the XSLT fragment:
>
> <xsl:for-each select="/foo">
> <xsl:apply-templates select="document('soap://..../func1')"/>
> <xsl:apply-templates select="document('soap://..../func2')"/>
> </xsl:for-each>
>
> Suppose there are six foo elements. First, func1 may get called six
> times. But it may also get called once. Or twice. The XSLT specification
> does not say.
>
> Second, func2 may or may not get called after func1. It might get called
> *before* func1 if the XSLT implementation had some reason for thinking
> that would be optimal. The XSLT specification does not say.
Didier replies:
So, this is not a problem, both SOAP URIs are not modified when the XSLT
template is processed, thus, we'll obtain the same result for each
transaction. There is only a problem if there is a sequence dependency
between the two invocations. But anyway you'll have the same problem a URL.
The XSLT engine may decide that the transactions are not performed in the
order requested and there would be no impact in the case of a URL or soap's
URI transaction if there are no strict sequence ordering requirements. As
illustrated with the Merkaat example, you'll have the same result both with
a soap's URI or a URL transaction. In both cases if the URL is used to
obtain stock quotes in real time, you may end up with a different document
for each invocations But I guess the template author knew that and this is
precisely the desired result. So far, so good, we have the same problems or
desired effects both for URLs and soap's URIs.
Paul said:
> >... Also, I am not sure if
> > this is what you mean and your comment confused me but for a given SOAP
> > call, if I invoke a SOAP server with the same URI I get the same result.
>
> Not really! You'd be pretty annoyed if every time you called
> getStockQuote you got back the same result.
>
> >...
> > For instance the Merkaat service[2] will send you back different
documents
> > based on the "_fl" parameter. This parameter can takes at least 6
values.
> > Then the following two URLs lead to a different result but may be
> > interpreted as an interaction with the same abstract resource (dependent
on
> > you mental model about what is a resource).
> > a) http://meerkat.oreillynet.com/?_fl=rss
> > b) http://meerkat.oreillynet.com/?_fl=xml
>
> You're talking about something unrelated. Those are two completely
> different URLs.
Didier replies:
So, the inherent mental model that you have about resources vs. URLs is that
a URL=resource. In that case, consider that:
a) soap://merkaat.oreilleynet.com/soap_service?get_document("rss")
b) soap://merkaat.oreilleynet.com/soap_service?get_document("xml")
are two different resources since the string of characters are different =>
the URIs are different => therefore they refer to two different resources.
as it is the case with the service invoked with an HTTP call, the returned
result may be different in time. New stuff may be added or removed each time
we perform a soap's URI transaction. But this is also the case with URLs
anyway.
The problem with the resource=URL is when at the other end we have a process
returning customized data or parameterized data. This leads to the equation
returned result = resource. The other view of the world leads to different
conclusions like, the resource is identified by the invariant part of the
URL, its facets by the variable part. Therefore, in that case, I recognized
that the returned result is different from the resource and I got only a
fragment of the complete resource.
So: model 1 (resource = URL = returned data)
a) http://www.mydomain.com/abstract_name?chapter=1
b) http://www.mydomain.com/abstract_name?chapter=2
c) http://www.mydomain.com/abstract_name
are three different resources even if (a) and (b) are two fragments of
resource (a)
Model 2 (resource = invariant part)
I may infer that the resource is identified by (c) and that (a) and (b) are
probably fragments of it. However, nothing is indicated in the specs that
may lead me to this conclusion.
If the official W3C version is that model 1 is the only *official* model,
then we deduce that *in reality*
a URL = a resource = a returned result, therefore a resource = a returned
result which is a more precise definition and a conclusion we inferred by
following the strict rules of aritotle logic.
According to Model 1 a resource is what is returned by a soap URI not what
is invoked by the URI.
But in order to convey more information about the end object let's say that
a soap URI is based on model 2. The invariant part indicates the resource,
the variant part indicates a method/function. We then now convey to the
client the notion that the whole may be different than the parts, that the
resource is not equal to the returned data but that the resource returns
data.
|------------------- invariant part ---------------|---- variant part------|
soap://merkaat.oreilleynet.com/soap_service?get_document("xml")
In model 1, there is an implicit assumption that what is identified by a
domain name is a resources provider. In model 2, the domain name is a
resources host.
Two different views of the world and a different set of information conveyed
within their respective name space identifiers.
cheers
Didier PH Martin
cheers
Didier PH Martin
