On 07/12/06, Alexander Johannesen <[EMAIL PROTECTED]> wrote: > > > > > > > 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?
"do a get a follow your nose" > > > > 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? Upset? Nope I'm stunned and disappointed. When I do an integration project the first thing is to get the interfaces defined and agreed, so if REST doesn't allow that (and I really can't believe it doesn't) then that is a massive risk on the project. What is the standard way in REST of communicating all of this meaning to the consumer? > > > > > 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? Interface definition is a fundamental requirement for professional engineering IMO. Having a standard way of describing these things is a base requirement for complex environments. > > > > 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. Meaning is exactly what I make of it, and when I have all the WS-* information available them I'm able to make a hell of a lot of meaning (correctly) out of the provided artefacts. If using REST I'd need to do the same, but REST doesn't appear to have a standard way of publishing this information to consumers. > > > > 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. Sorry it was Jan who said that. I get confused easily with all the contradictions coming in this thread! > > > > 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? 1) It might not have been built yet 2) I need to publish the information to the consumers 3) That information acts as a formal contract between the two areas 4) Call it and see cannot be viable for full traversal (I can't guarentee full coverage as I don't know what I'm looking at) 5) Communicating change via "it is now broken call it again to work out how it works now" isn't viable. I could go on, but having an integration project (which is what REST and WS-* are) without formal interfaces is (IME) project suicide. > > Alex > -- > "Ultimately, all things are known because you want to believe you know." > - Frank Herbert > __ http://shelter.nu/ __________________________________________________ >
