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> 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
> Phone: +1 812-482-5224****
>
> Cell:  +1 812-630-7622
> www.marklogic.com
>
> ****
>
> ** **
>
> *From:* Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca]
> *Sent:* Tuesday, September 24, 2013 2:47 PM
> *To:* mca; David Carlisle
> *Cc:* 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]
> *Sent:* September 24, 2013 13:26
> *To:* David Carlisle
> *Cc:* 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
> 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> 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.
> ________________________________________________________________________**
> **
>
> ** **
>
>