On 8 April 2010 04:31, Stuart Charlton <[email protected]> wrote:
> > > Comments inline > > Sent from my iPad > > On 2010-04-07, at 2:56 PM, Steve Jones <[email protected]> wrote: > > >> >> And yet there still is plenty of reason to be frustrated. Crappy REST >> Apis abound, data still isn't any more interoperable with JSON, and HTML5 is >> deep in a mire... >> > Yup. Which I think stems from the original objections of the REST > community to having a more formal interface description language. > > > That will change, IMO. Not holding my breath, of course. > God I hope so. Its such a ruddy obvious practical gap even if "theoretically" dynamic discovery is best. > > > >> And I think a huge difference is that, no they're not building them the >> way they always have. issuing SQL via VB or Powerbuilder was predominant... >> the use of URI and HTTP are big, interoperable differences. Even for those >> trying to being that old model back for the Web (like Microsoft with OData) >> > > Is that really a big difference? Sure the technology has changed but SQL > was the "equivalent" back then. Sure HTTP/URI is more open but the net > effect is still client/server just using a different (but better) technical > protocol. Architecturally its the same even if in implementation its > different. > > > Architecturally it is an evolution of client/server. The big difference is > on the data elements and in interface uniformity. That's a pretty big deal > for interoperability. > Isn't SQL a uniform interface over ODBC/JDBC? > > >> I'm curious what vision this is.... that everything would be magical and >> automatically interoperate without work? or the current reality of Mashups >> and crappy REST APIs that are reasonably easy to build and consume? >> > > This was the "vision" that MIME and "dynamic" REST based interfaces would > enable the "automatic" consumption of services. > > Its me grumbling (yet again) that the technical myth of dynamic interfaces > is rubbish while more structure published approaches (such as the Apple > APIs) seem to actually work despite their technical "limitations". > > > Firstly, I don't think dynamic interfaces are rubbish. I'll admit the jury > is still out. > I think they are rubbish for the mainstream, its one of those "nice" things like proper concurrency where very very few people can actually handle it. > > Second, Apple's APIs are for the UI, not networked information exchange. > They are for on device stuff with minimal connection stuff, my point though is that having a fixed set of APIs actually gets the vast majority more productive quickly. > > > The challenge is conceptual change not technical change. > > > They are reflexive, in that they both influence each other. > Ummmm I agree that there is some mutual influence but the biggest change is always in the thinking not in the technology. > > > >> I'll give you that Client/Server is still Client/Server even on the Web. >> But the infrastructure people build client/server apps today allows them to >> consume content from across server implementations, trust domains, and >> geographies -- something you could never do twenty years ago. >> > > I worked on programmes where we exchanged information between systems > across geographies and domains but in a very restricted domain. I'm not > disagreeing but just saying that its the conceptual model that matters more > than the technical one in actually delivering change and we haven't created > a decent conceptual model to really replace client/server. > > > I think one of the troubles is getting the terminology right. I have a > feeling that what you call client/server is much broader than what I have in > mind. I continue to work with and seek extensions to REST because I think > the data elements in an architecture have huge impact on scale and interop, > more than just the topology of roles of the components themselves (c/s, p2p, > etc). The web is a client/server topology with a p2p data model. > I'm not disagreeing on that and I do think that some of the REST elements, if properly documented, could deliver some real benefits. > > > What we do continue to lack are ways to make data content itself more >> interoperable, as the Semantic Web learning curve is pretty steep if you >> just want a little semantics. Though I see some positive signs there too, >> even if it will take a while... >> > > I think the Semantic Web stuff is a bit rubbish to be honest. I don't > think the maths behind it stack up and again I think that explicit > ontologies are better than dynamic ones. > > > Having worked with RDF and OWL regularly for 2 years, I believe the maths > behind the SemWeb aren't new, in fact they're the most solid aspect of those > technologies, though they have the highest learning curve. The Web part is > what is new. SemWeb is all about explicit ontologies. I don't quite know > what a dynamic ontology is... certainly it's not in widely deployed practice > to my knowledge, so I'd gladly call it rubbish. ;) > I got into the Semantic stuff at an IEEE conference in 2002 where people were chuntering along about semantic matching and dynamic matching between ontologies (one ontology says "car" another says "automobile" then some clever maths will manage to match it about 85% of the time). The semantic web in terms of having explicitly agreed ontologies is a great idea and one I use pretty much daily. I just don't think this really counts as semantics as you are using a limited dictionary and really just tagging. Steve > > Cheers > Stu > > > ------------------------------ > Ask a question on any topic and get answers from real people. *Go to > Yahoo! Answers.* <http://ca.answers.yahoo.com> > > >
