RE: Open systems / Freedom ( was RE: The Web as an Application)

This proposed @type semantics:

http://www.w3.org/community/xmlhypermedia/wiki/SpecificationDraft

Relative to Mike's question 1) below, I think the point is that the web is a communication system wherein the type of the resource is a separate concern from its identifier.  If all resources on the web are of the same type, there is very little need to worry about what is returned: either you 'understand' it, or you don't.  In the html web, everything is either an html page, an image or a Save As..., to make a long story short.  But if there are *other* possibilities, i.e. a heterogeneous web,
then you need to communicate what you want / expect to receive.  That is where media types come in.  A resource can reasonably have more than one choice of representation that could be considered application/xml. (e.g. application/atom+xml or application/rss+xml or application/xhtml+xml).  Which do you want?

The @type models the network request's Accept header, or at least a suggested aspect of it.  Its presence in the response body would be guidance from the server to the client as to what to / could be requested.

The problem with the term REST API is that services like Amazon have coopted it so that it has come to mean virtually anything.   But if you look back at the manual, what it actually means relies on hypermedia, like @type.

Actually, the web has the protocol already built to deal with 2):  Content-Type or 406.  If your Accept possible for the resource, the protocol header would identify the the result and you could activate the appropriate code without having to sniff the content.  If your accept was not possible, I think there are many possibilities, but one that might be reasonable is the 406 http code.  That might also cover off the situation for 3)

The difficulty for someone like me is not only misrepresenting this subject, but also under- or over-explaining it.  But I think it is worth discussing.


Peter



________________________________
From: David Lee [mailto:David.Lee@marklogic.com]
Sent: September 25, 2013 12:11
To: mca
Cc: public-xmlhypermedia@w3.org
Subject: RE: Open systems / Freedom ( was RE: The Web as an Application)

So first to answer the questions ... And my answers will expose why this whole thing confuses me.

1) did you know about all the namespaces that would show up on the response _before_ you made the request? if yes, how?
Yes.  My app when doing a request knows what kind of data its going to get, otherwise it wouldn't know either why
it is asking for it or what to do about it if it was wrong.
I have never written an app that is expected to handle data it doesn't have a clue about beforehand, and I have a hard time conceiving of one that could.
Take your typical REST call to a service (say like Amazon) ... I need to know beforehand even before doing the request the format of the data to send and what to expect (within a predefined set).



2) if you did not know about all the namespaces that would show up in the response beforehand, how did you handle the "unexpected" namespaces?
They would be an error.


3) in your work what is the likelihood that you will encounter a response that has an unexpected namespace at runtime? when it occurs, what happens?
It would be an error equivalent to a 404 if the data was totally unexpected.

----------

So this should expose my complete misunderstanding about what were trying to achive.
To make progress I suggest we proceed as Peter suggested:
Lets get over (for now) the namespace issue and see if we can come up with some *semantics* ...

--- Peter :



But, if there is interest in your option 3, I don't want to be the block on that.

If the group thinks that's the right direction, please move on with that.
----

I.e. I suggest we try to define the various attribues or elements in a namespace and define what they mean
and work out use cases where we can describe how an application would actually make use of them.







-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
www.marklogic.com<http://www.marklogic.com/>


From: mca [mailto:mca@amundsen.com]
Sent: Tuesday, September 24, 2013 5:01 PM
To: David Lee
Cc: Rushforth, Peter; David Carlisle; public-xmlhypermedia@w3.org
Subject: Re: Open systems / Freedom ( was RE: The Web as an Application)

David:

Yes, namespaces are definitely inline information about the data.

some questions on your example:
1) did you know about all the namespaces that would show up on the response _before_ you made the request? if yes, how?
2) if you did not know about all the namespaces that would show up in the response before hand, how did you handle the "unexpected" namespaces?
3) in your work what is the likelihood that you will encounter a response that has an unexpected namespace at runtime? when it occurs, what happens?

FWIW, i think this community was formed to deal not w/ describing data (that's more than adequately covered in XML today), but to come up w/ a generic way to describe network actions.


mca
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Tue, Sep 24, 2013 at 4:36 PM, David Lee <David.Lee@marklogic.com<mailto:David.Lee@marklogic.com>> wrote:
This confuses me greatly.
If an application knows the document is xml (say via a media type derived from application/xml) then the next step I would take as a consumer of the data would be to look
at the namespace of the root element.   That tells me more about the data then anything else.
This is *in band* information not *out of band* information.

Since the media type and the XML content itself is provided in the same HTTP response I dont understand the concept that
the media type is the only reliable semantics.

I have never once had to use nor seen any value in using a media type more specific then application/xml or text/xml


Could you expound on this ?  Maybe I just dont "get it".

-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com<mailto:dlee@marklogic.com>
Phone: +1 812-482-5224<tel:%2B1%20812-482-5224>
Cell:  +1 812-630-7622<tel:%2B1%20812-630-7622>
www.marklogic.com<http://www.marklogic.com/>

From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca<mailto:Peter.Rushforth@NRCan-RNCan.gc.ca>]
Sent: Tuesday, September 24, 2013 2:47 PM
To: mca; David Carlisle
Cc: public-xmlhypermedia@w3.org<mailto:public-xmlhypermedia@w3.org>
Subject: RE: Open systems / Freedom ( was RE: The Web as an Application)

In a RESTful system, the (only?) reliable message semantics metadata across servers and clients is the media type.

If you stray outside the media type definition, you are relying on out-of-band semantics.  That might work where you
control the client and the server, but it doesn't scale: application/xml may be a purchase order on my system, but may be a
personal health record in a hospital system.  The only thing those two messages may have in common is
that they have angle brackets.

So anything that implies only what the XML specification implies is not communicating very much to
potential consumers: the least common denominator, as it were.  The suggestion is to add links to that.  It's the web, after all.

Here's another alternative:

Since the definition of xml is separate from the registration of the application/xml media type (from Liam's earlier message),
 what about adding links to the registration only? You don't have to change the definition of xml then, just its definition on the web.

Regards,
Peter




________________________________
From: mca [mailto:mca@amundsen.com<mailto:mca@amundsen.com>]
Sent: September 24, 2013 13:26
To: David Carlisle
Cc: public-xmlhypermedia@w3.org<mailto:public-xmlhypermedia@w3.org>
Subject: Re: Open systems / Freedom ( was RE: The Web as an Application)
registered mime types are important to the web.
working parsers for registered mimetypes are even more important.

the advantage that the XML family has is that it is relativity easy to design and ship your own custom parser (XSLT) with each and every snowflake message design you care to invent.

as long as you only want to speak in XML, all is fine. start using plain text-based formats, JSON-based messages, videos, and other binary messages and suddenly shipping your parser with the message gets a lot harder.

this is all old news.


mca
+1.859.757.1449<tel:%2B1.859.757.1449>
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Tue, Sep 24, 2013 at 1:13 PM, David Carlisle <davidc@nag.co.uk<mailto:davidc@nag.co.uk>> wrote:
On 24/09/2013 17:42, Rushforth, Peter wrote:
What's astonishing is how many XML vocabularies rely only on
application/xml on the web.

Why is that surprising at all?

If you have a a vocabulary served as application/xml it can in many
cases just automatically do the right thing, especially if coupled with
an in-document processing instruction such as xml-stylesheet.

If you invent a new xml vocabuary and give it a new mime type, there are
typically few advantages and a massive disadvantage that the default
behaviour for every application is to drop it on the floor as an unknown
mimetype.

We (finally in MathML3, after 15 years of MathML) got round to
registering a mime type for MathML, because some people would find it
useful, but it is of very limited use on the web (most convincing use
case for it is labelling clipboard formats on some operating systems)

David

________________________________________________________________________

The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. ________________________________________________________________________