Hi,
On 12/7/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> So I have to guess what the structure of the invoice is and to guess
> which link goes to the customer and which link goes to the supplier
> and which link goes to each of the various products?
No, there's no guessing here. Why are you saying that?
> > An invoice is probably an application of
> > XML, in which you inspect the XML to see if you understand the schema
> > it was written in. If it was, then you're good to go.
>
> So you have to communicate the XML Schema associated with the URI
> before someone uses it.
Not sure I understand what that means. Are you mostly upset because
you can't upfront know what the schema is? And if so, why is this a
problem?
> > > How do I know how to get from invoice to customer?
> >
> > How do you do that on any other stack, or any other technology?
>
> Well with a WSDL I get given the Schemas upfront and these are
> consumed into the tools so I can see these within my IDE.
Some do repositories similar to WSDL, some do it in RDF/XML, I do it
in a TM based schema, some do it even in WSDL. Does this automata
*really* matter? Does it *really* solve big issues, or is it a
nice-to-have feature?
> > When you browse a URL, what does it mean? When you use a SOAP service,
> > what does it mean? When communicating on this mailing-list, what does
> > it mean? I think you're stretching the term "meaning" here ... :)
>
> No I'm not. When I use a SOAP service I have the name of the SOAP
> endpoint and the port as well as the schemas that define the
> documents. There is the concept of this being published upfront in a
> standard way, with Service names and ports having sensible and
> descriptive names.
All you have through this is your connection points, schemas, API's
and so forth. This is *not* meaning. Meaning is what you make of it.
Full automata of services is a pipe-dream, no more realised with WS-*
than anything else. In the end, there's developers like you and me
deciding what to connect to where and how to use it.
> > The *meaning* of a URL is whatever we make it. There's guidelines
> > which says we should make URL's as meaningful as possible, but there's
> > no requirement to do so. But if we can, we should, just with any other
> > URL out there; REST builds on some nice human principles of
> > exploration that I find very attractive.
>
> Hang on you said it was Opaque and now saying it should be
> meaningful.... which is it?
*I* certainly didn't say "opaque" ... I'm much too simple to use such words.
> > Sounds like you're trolling...
>
> Not at all, having an approach which is "call it and see" isn't really
> viable commercially.
Why not, exactly?
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
