http://permalink.gmane.org/gmane.comp.web.services.rest hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.services.rest/8867 Oh yes, its going to take a long while. Look how many decades its taken to go from umpteen network architectures to IP! This is hard work. But it is what REALLY causes business transformation. We will go from thousands of variations, to hundreds, to dozens, to a handful ... over decades. Look at how many healthcare related coding schemes there are internationally! But the sooner we get our heads out of the weeds of SOAP vs whatever debates and focus on BUSINESS-LEVEL interoperability issues, the sooner we'll get there. I can't tell you how many IT executives think that just incanting "SOA" and buying some XML/WS-* technology just makes all this business-level interop just happen. We need them to refocus on business standards instead of wasting their time on technology standards. The technology standards are EASY by comparison. Nick Gall 2008-12-02T03:54:29 http://permalink.gmane.org/gmane.comp.web.services.rest/8866 identifiers". (I am ignoring generic protocol operations since that is same as saying "uniform interface"). What do you mean by "generic identifiers" in the context of REST? There are many examples of generic identifiers. We just need to map existing ones into URLs and begin creating new identifier standards with the URL syntax as the default. Here is a short list of well known generic identifiers: 1. UPC/EAN product codes (which have now been generalized to include ISBN and ISSN) 2. ISO 1366 geographic codes 3. International Statistical Classification of Diseases and Related Health Problems (ICD) 4. DUNS numbers Every industry has myriad master/reference data standards that are "application neutral" aka "application generic". Contrast this with enterprises or applications that use "application specific" product identifiers, country identifiers, disease identifiers, business identifiers. The web has a longer way to go here (promoting generic identifiers). A good start would be standard' Nick Gall 2008-12-02T03:43:59 http://permalink.gmane.org/gmane.comp.web.services.rest/8865 I guess the other question (ignoring for the moment whether "application neutral" is a felicitous phrase) is: how neutral is it, really? For example, if you put your head around some merger of REA/ebXML/UNCEFACT/UBL/OAGIS and add some standard protocols for message interactions, you still end up with protocols for e.g. negotiating purchase orders. And the purchase order protocol will not work for deliveries or returns or (heaven help us) mortages. And even the purchase order protocol will have several variations, depending on whether the purchaser wants a quote first, who pays for transportation, and several other piddly business details. So the buyer and seller might be able to use different application software (that was the OAGIS promise, seldom really fulfilled) but it's still just purchasing. Bob Haugen 2008-12-02T03:13:38 http://permalink.gmane.org/gmane.comp.web.services.rest/8864 On Dec 1, 2008, at 8:19 AM, Mike wrote: Not sure. In the context of the web, URIs are identifiers, but I don't think Nick is referring to URIs here. Subbu --- http://subbu.org Subbu Allamaraju 2008-12-02T03:06:10 http://permalink.gmane.org/gmane.comp.web.services.rest/8863 have in mind though? I ask because using fragments such as "not too neutral" seems to indicate there might be an issue with the chosen word to begin with. Maybe I've spent too much time around Swiss colleagues and friends, but there is no such notion as "too neutral." Someone/something either is neutral or it is not neutral (i.e. leaning towards one side or another, however discreetly). Sorry, "not too neutral" was simply a play on the famous simplicity quote attributed to Einstein: "Make everything as simple as possible, but no simpler." Thus "make interfaces as application neutral as possible, but no neutraler [sic]." "generic." If I rewrite your response above using "generic" instead, we get the following: All aspects should be as generic as possible (but not too generic), not JUST the data and the data model. make the IFaPs too generic and your application will not work (insufficient information density); make them too specific (too much information density) and only your application will understan Nick Gall 2008-12-02T03:02:59 http://permalink.gmane.org/gmane.comp.web.services.rest/8862 Thanks for the responses. Here are more details - My scenario is the following: I have a provisioning API which lets each application register with the platform URL: http://www.fooplatform.com/directory/API_ID Header: Some auth information Payload: <app> <name/> <description/> </app> I the application to have ability to submit localized version of the above directory information: For eg <app> <name>foo</name> <description xml:lang="fr">Comme vous </description> <description xml:lang="en">how are you</description> </app> The directory of application is localized http://www.fooplatform.com/directory/en/ Will display all the application and descriptions in english, the following one is french http://www.fooplatform.com/directory/fr/ Is the above use of xml:lang correct? How should i modify the schema for the initial xml given that descrition had minOccurs=1 and maxOccurs=1, how will the attribute be accounted for? How should the processers for the directory handle the xml:lang attribute. Any general tho vbzpanacea 2008-12-01T22:59:06 http://permalink.gmane.org/gmane.comp.web.services.rest/8861 Identifiers identify resources only? Mike 2008-12-01T16:19:22 http://permalink.gmane.org/gmane.comp.web.services.rest/8860 Actually, identifiers have probably been more successfully standardized than any of the other pieces of that puzzle via UPC bar codes. I think there's a lesson somewhere in there. The protocols proved to be more difficult. ebXML and UN/CEFACT tried to define them, but got a lot of resistance ("we don't need that"). And if course when attempted, they were not defined in any RESTful way. Bob Haugen 2008-12-01T15:40:48 http://permalink.gmane.org/gmane.comp.web.services.rest/8859 I am working on a new resource-oriented library for ASP.NET MVC. The motivation is to create an API centered around strongly typed URIs, Resources and links between them. I have created a screencast that shows it in action: http://www.aboutcode.net/2008/11/26/New+ResourceOriented+Library+For+ASP NET+MVC.aspx A SVN link to the code is also linked from the above page. All feedback is appreciated. Andrew Davey 2008-12-01T10:09:27 http://permalink.gmane.org/gmane.comp.web.services.rest/8858 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40348 All too true. Thanks for the reality check. Though my point in referencing the accounting article was simply to establish that "application neutrality" is not some vague term coined by Gartner, but meaningful term applied in diverse areas, let me make one comment about the examples you cite. No one said it would be easy! Standardizing "business" identifiers, formats, and protocols within and across industries is MUCH harder than standardizing the technical standards for serializing it, transporting it, and parsing it. That's why the WOA note essentially states: Stop worrying so much about "implementation neutrality" and start focusing on "application neutrality". That's where the big payoff is. One other lesson to be gleaned from the EDI era: standardizing formats (eg media types) is not enough. You must also standardize the reference data/master data (aka identifiers) that are poured into such formats. You must also st Nick Gall 2008-12-01T14:38:04 http://permalink.gmane.org/gmane.comp.web.services.rest/8857 Reality check re the REA model: I was one of the people who tried to define that as a standard format at least for B2B interactions. I worked on this issue with ebXML, UN/CEFACT and ISO. To some extent, REA is incorporated in the "standards" of each of those organizations. Explicitly so for ISO: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40348 ebXML and UN/CEFACT also tried to "standardize" an application protocol for exchanging business messages using a somewhat-REA-based vocabulary. The reason I put quotes around "standardize" is that all three of those groups claimed to provide "standards", all three coming from the same background sources (EDI and REA), and all three are slightly different. Likewise OASIS Universal Business Language (UBL) http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl also spun off from ebXML, and claims to provide yet another "standard" B2B vocabulary, derived mostly from X12 and EDIFACT EDI without any REA influence. And then Bob Haugen 2008-12-01T14:04:17 http://permalink.gmane.org/gmane.comp.web.services.rest/8856 I wonder if "neutrality" is really the best word to convey the concept you have in mind though? I ask because using fragments such as "not too neutral" seems to indicate there might be an issue with the chosen word to begin with. Maybe I've spent too much time around Swiss colleagues and friends, but there is no such notion as "too neutral." Someone/something either is neutral or it is not neutral (i.e. leaning towards one side or another, however discreetly). IIRC, the notion of "neutral" was introduced as an alternative to "generic." If I rewrite your response above using "generic" instead, we get the following: This statement is something that my brain can understand in graduations: make the IFaPs too generic and your application will not work (insufficient information density); make them too specific (too much information density) and only your application will understand them. In other words, tune the IFaPs for the "necessary and sufficient" amount of information dens Steve Bjorg 2008-12-01T06:47:40 http://permalink.gmane.org/gmane.comp.web.services.rest/8855 Nick - my comment was not that I don't understand what this term means. IMHO, it is too broad to describe what you were trying to describe. The fact that this term was used in various contexts does not change that. When you add a new item to a list of constraints, it of course deserves extra scrutiny. At least on this list, a number of people sincerely want to understand and debate, and so, let us not worry about "sink in". Now that we agree on the media type aspect, let me ask you about "generic identifiers". (I am ignoring generic protocol operations since that is same as saying "uniform interface"). What do you mean by "generic identifiers" in the context of REST? By the way, since the actual report is not public, it is very very difficult to understand what this is all about. If this has been discussed, please provide public references. Subbu Subbu Allamaraju 2008-12-01T05:41:31 http://permalink.gmane.org/gmane.comp.web.services.rest/8854 Thanks for the quick reply. I asked the question because, to date, my understanding of the phrase centered around data (both stored and passed via messages). For example, I recall some material on Data Warehousing several years ago produced by Gartner that talked about "application neutrality" - again that was (IIRC) data and data model related. Also, I understand Fielding's work as identifying a set of *contraints* that, when followed, result in optimal network-based architectures. Seeing you list "application neutrality" among these leads me to believe you see this as another constraint that optimizes network-based arch. Is that correct? MCA On Sun, Nov 30, 2008 at 22:39, Nick Gall <nick.gall< at >gmail.com> wrote: mike amundsen 2008-12-01T04:11:42 http://permalink.gmane.org/gmane.comp.web.services.rest/8853 --- In rest-discuss< at >yahoogroups.com, "mike amundsen" <mamund< at >...> wrote: model. Is "Application neutral" is to be applied to all aspects of an interface. All aspects should be as neutral as possible (but not too neutral), not JUST the data and the data model. My accounting example simply emphasized the data model aspect. Nick Gall 2008-12-01T03:39:39 http://permalink.gmane.org/gmane.comp.web.services.rest/8852 Nick: Reading your example reference document leads me to understand that "application neutral" is to be applied to data and to the data model. Is that correct? mca http://amundsen.com/blog/ On Sun, Nov 30, 2008 at 22:10, Nick Gall <nick.gall< at >gmail.com> wrote: mike amundsen 2008-12-01T03:21:28 http://permalink.gmane.org/gmane.comp.web.services.rest/8851 it Sorry you find "application neutrality" so vague. Having used the term with many people over the past couple of years, you're the first person to find it so troublesome. It gets over 12,000 hits on Google as well. Perhaps the following example from the accounting domain will help you understand the use of the term better: Research initiatives in the domain of accounting information systems have predominantly resulted in proposals of new accounting data models, which can store objective, so-called 'application-neutral' data. These are data models that are defined independently of any application scope. They can therefore guarantee the availability of useful data to support a wide range of existing and new applications. The most prominent research results in the area of accounting data models include: principles of data recording of 'Grundrechnung' (Riebel, 1994 based on Schmalenbach, 1948, 1956) and the '(extended) REA model' (McCarthy, 1982; Geerts and McCarthy, 2000, 2002). Some authors have argued th Nick Gall 2008-12-01T03:10:30 http://permalink.gmane.org/gmane.comp.web.services.rest/8850 Agreed. But some are more widely used than others. That's the point I continue to press: Start with the most widely used application interface "framework" (eg APP -- by framework I mean nothing more than a set of constraints) that could possibly work for your application. When you specialize it to your needs, find the most general way to specialize it that can possibly work. If you recursively follow this process, you stand a better chance of having the interface you've designed become widely used as well. No argument. The HTTP/MIME media type declaration architecture is serious need of a major overhaul. ... Perhaps that's the nub of the issue. I have VERY low expectations regarding user agents doing sophisticated automatic interface inference and negotiation any time soon. IMO too much wasted effort goes into this AI-hard problem. CORBA tried it. WS-* tried it. Semantic Web is trying it. Such attempts add major complexity in return for little or no results -- so far. Someday? Maybe. I'm just looking f Nick Gall 2008-11-29T16:30:45 http://permalink.gmane.org/gmane.comp.web.services.rest/8849 Nope :) Putting a one-off representation of a one-off media type inside a generic media type is NOT stepping off the generality cliff. That is what media types are meant for. Media types describe the "type" of a representation. In fact, folks coming from the WS-*/schema background should love media types. Concrete media types describe the data. Where as, extensions added to general purpose media types do so only weakly. It is not a "nested" application protocol. APP is just a profile of HTTP for a certain class of resources, viz., feeds and entries. GData is an APP like protocol, and in Google's words "GData is a new protocol based on the Atom 1.0 and RSS 2.0 syndication formats, plus the Atom Publishing Protocol." The statement on "RESTafarian insistence that HTTP is NOT a transport protocol" prompted my question. Now I understand that it is rhetorical. That is a choice that the server app will have to make based on the kind of clients it is expecting to serve. If its its clien Subbu Allamaraju 2008-11-29T08:13:25 http://permalink.gmane.org/gmane.comp.web.services.rest/8848 They're all idiosyncratic. Ok, so let's take RDF and OWL. These two are linked via rdf:class, but they have different semantics (in the formal sense, their model theories are not the same). What this means is that if you serve OWL content using an RDF media type, consuming clients are not expected to consume it with an OWL reasoner and if they do, any inferences drawn by an OWL applying client can be repudiated by servers. It's not actually OWL according to Web architecture. Now add in the XML media type. If I serve an RDF document as application/xml can you apply an RDF reasoner to it? What about FOAF? Or an HTML page with hCard, SVG, RDFa and hAtom? It's all undefined. Dropping down to lexical forms and namespaces, if I serve an Atom feed as application/xml, are you allowed to consume it as Atom? And if you are, in what can clients reasonably expect servers to stand over? What about those DRM and other extensions people are going to add as AtomPub sees wider adoption for integrations? As Bill de hOra 2008-11-29T01:59:34 http://permalink.gmane.org/gmane.comp.web.services.rest/8847 Ok, so let's take RDF and OWL. These two are linked via rdf:class, but they have different semantics (in the formal sense, their model theories are not the same). What this means is that if you serve OWL content using an RDF media type, consuming clients are not expected to consume it with an OWL reasoner and if they do, any inferences drawn by an OWL applying client can be repudiated by servers. It's not actually OWL according to Web architecture. Now add in the XML media type. If I serve an RDF document as application/xml can you apply an RDF reasoner to it? What about FOAF? Or an HTML page with hCard, SVG, RDFa and hAtom? It's all undefined. Dropping down to lexical forms and namespaces, if I serve an Atom feed as application/xml, are you allowed to consume it as Atom? And if you are, in what can clients reasonably expect servers to stand over? What about those DRM and other extensions people are going to add as AtomPub sees wider adoption for integrations? As far as I can tell, this is b Bill de hOra 2008-11-29T01:45:20 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.services.rest