Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-02.txt

From: Conal Tuohy <[email-masked]>
Date: Mon, 07 Jan 2013 18:00:13 +1000

On 17/12/12 15:34, Mark Nottingham wrote:
>> Using namespaces to disambiguate XML vocabularies is considered best practice. It allows for an XML document to be correctly interpreted even outside the HTTP context in which it might appear (i.e. without knowing the specific internet media type). See http://www.w3.org/TR/webarch/#xml-namespaces for details, and also see http://www.w3.org/TR/webarch/#namespace-document for the reasons why namespace URIs should resolve to useful documentation (such as an RFC document).
> Yes, I'm familiar with the WebArch document. In practice, XML Namespaces can cause a lot of developer confusion, and I'd put forth that they should only be used where distributed extensibility is necessary, and there are no other ways to achieve it.
I beg to differ. I agree with Erik, there. Many developers (especially 
those without much XML experience) don't like XML namespaces, and 
there's no doubt they are a complication of the original XML model. But 
like them or not, they are THE standard way to handle mixed vocabularies 
in the XML world, and I firmly believe that more XML developers would be 
confused by XML documents in which vocabularies are re-used and mixed 
WITHOUT the help of XML namespaces. To be honest the idea of not using 
XML's standard namespace mechanism for its God-given purpose seems 
wilfully deviant to me.
> Here, because the definition of the problem type (and thereby, its extensions) is controlled by the person that mints it (using a describedBy link), there isn't a need for distributed extensibility, as far as I can see. Furthermore, using XML namespaces would force the use of a similar mechanism with JSON, which would make me (and many others, I think) unhappy.
Yes, the "describedBy" link in the current draft is a namespace 
mechanism as well, but it applies holus bolus - it's not clear how one 
could use it to handle cases where a problem type is itself a composite, 
i.e. where I have a problem which I wish to describe using multiple 
vocabularies. A couple of examples:

  * I might have a common low-level vocabulary shared by many apps, and
    other, more domain-specific vocabularies, for describing an error in
    more high-level terms. Analogously to how Java exceptions can model
    high-level (more user- and action- oriented) errors, and also
    contain nested within them exceptions which model more low-level
    (system-oriented) descriptions of the same error.
  * I might also have a web service which is a mashup of two other web
    services, each with their own vocabularies. A client app might
    attempt some erroneous operation on the mashup, generating two
    erroneous operations on the aggregated services, and producing a
    single error, containing two underlying errors.

>> It seems to me that the relationship between the names of JSON objects and corresponding XML elements also needs clarification.
>>
>> For instance, the XML schema allows those objects to be in "##any" namespace, but how would those namespaces relate to JSON expressions of the same error report? If a JSON problem report were to be transformed into XML, what XML namespaces would actually be used for any extension members? Conversely, if an XML-formatted problem report were converted to JSON, how would any XML namespaces be rendered in the JSON?
> I'm CC:ing Erik because he helped me add the XML format (which I was somewhat reluctant to do).
>
> No namespaces would be used, as I understand it. Erik, does the schema need revision?
Yeah, that would resolve the issue of how namespaced extension 
properties would be represented in JSON, but to my mind it would be an 
unnatural act, from the point of view of XML ;-)

An alternative would be to extend the "describedBy" feature to extension 
properties. It seems to me that already a JSON problem object could be 
converted to XML in which which all the extension properties were 
elements whose names were in the namespace defined by the "describedBy" 
URI. If those extension objects contained "describedBy" properties in 
turn, then they too could be converted to namespaced XML elements. It 
might be necessary to rearrange the structure of a problem object 
slightly to make that work, but I think it would be a minor change, and 
it would allow for problems to be composed out of other problems.

Regards

Con
-- 
Conal Tuohy
HuNI <http://huni.net.au/> Technical Coordinator 
<http://apidictor.huni.net.au/trac/wiki/ConalSpace>
Victorian eResearch Strategic Initiative 
<http://versi.edu.au/about-us/versi-team#Con>
Skype: conal.tuohy
Twitter: @conal_tuohy <https://twitter.com/conal_tuohy>
Mobile: +61-466324297 <tel:+61-466324297>

---

From: Erik Wilde <[email-masked]>
Date: Mon, 07 Jan 2013 14:09:20 +0100

hello conal.

> XML's standard namespace mechanism for its God-given purpose seems

for the record: i do agree that XML namespaces are what is used in XML 
to clearly separate vocabularies, and thus they should be the default 
choice for doing this. i also think that even though intensely disliking 
namespaces for a while seemed to be the hip thing to do, in the meantime 
things have cooled down a bit, and they are just a fact of life when 
you're dealing with XML.

that being said, however, what convinced me about mark's argument was 
the following: if you want to have a model that spans more than one 
representation (specifically, JSON and XML), and you don't want to be in 
the business of inventing namespaces in JSON, then avoiding namespaces 
in XML may be the best way to go. it still looks wrong to me, from the 
XML point of view, but from he "let's reuse the same model in JSON and 
XML" view, maybe it's the best possible way to go.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jan 2013 14:49:29 +0100

On 2013-01-07 14:09, Erik Wilde wrote:
>>> Yes, I'm familiar with the WebArch document. In practice, XML
>>> Namespaces can cause a lot of developer confusion, and I'd put forth
>>> that they should only be used where distributed extensibility is
>>> necessary, and there are no other ways to achieve it.

Erik: thanks for the explanation.

So what actually *is* the added complexity if we did use XML namespaces 
for the XML variant *only*?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Mon, 07 Jan 2013 16:00:45 +0100

hello julian.

> for the XML variant *only*?

it wouldn't be easy to define a straightforward mapping between the JSON 
and the XML representations. it would be strange (i think) to define a 
format where representing some resources in XML would result in very 
strange JSON, or might not even be possible. if you want to use 
namespaces in the XML, then they should be meaningful (for example, 
represent a special kind of extension through the namespace URI). but 
then how would you map this to the equivalent JSON? you'd have to define 
a generic namespace mapping from XML into JSON, or something specific 
for our format, and both options are not very appealing.

cheers,

dret.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jan 2013 16:50:00 +0100

> for our format, and both options are not very appealing.

I understand your point. Also I think that JSON should indeed have a 
mapping for XML namespaces (such as proposed by Peter St. Andre, if I 
recall correctly).

That being said: if *this* vocabulary used a namespace, it would still 
be trivial to map to JSON; as long as it's not being mixed with anything 
else. So where is the *actual* problem here, except that the XML variant 
would be more ... versatile?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Mon, 07 Jan 2013 17:01:42 +0100

hello julian.

> mapping for XML namespaces (such as proposed by Peter St. Andre, if I

well, i think the devil is in many details there, starting with 
different naming syntaxes and all of this then leaking into all 
technologies that are layered on top of JSON. for now, i think it's safe 
to assume that we will not have such a thing anytime soon.

> would be more ... versatile?

my initial proposal was to at least have a namespace in there for the 
syntax. however, it seems odd (at least to me) to use namespaces but 
then to not use them what they are intended for: to segment vocabularies 
and then have the standard namespace and allow extensions to add their 
own namespaced vocabularies. so if we accept that we're not using 
namespaces to keep vocabularies separate, then maybe using a single 
namespace is almost more confusing than using a non-namespace 
vocabulary. but i see that this may be a matter of debate, and if most 
people would prefer to have at least one namespace used for everything 
(instead of having none), then we can certainly go that route.

the downside of this is that i am fairly certain that implementations 
then will start using namespaces when they use the XML format, because 
as conal pointed out, that's the natural thing to do in an XML world. 
because of this, we should at least plan ahead and add some language 
that would say how to treat this kind of XML: ignore any XML not in the 
one blessed namespace? or ignore namespaces and treat all local names as 
if they were in the blessed namespace?

cheers,

dret.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jan 2013 17:12:24 +0100

On 2013-01-07 17:01, Erik Wilde wrote:
> ...

Another use case for XML namespaces is so that the elements of *this* 
vocabulary can be embedded more easily into *other* vocabularies. I 
would think it's ok if this would be a difference between the XML and 
the JSON side...

> ...

Um, no. There shouldn't be multiple element names for the same thing. 
Either stick with no namespace, or use a namespace, and use that 
throughout...

Best regards, Julian

---

From: Conal Tuohy <[email-masked]>
Date: Tue, 08 Jan 2013 08:16:09 +1000

On 08/01/13 01:00, Erik Wilde wrote:
> it wouldn't be easy to define a straightforward mapping between the 
> JSON and the XML representations. it would be strange (i think) to 
> define a format where representing some resources in XML would result 
> in very strange JSON, or might not even be possible. if you want to 
> use namespaces in the XML, then they should be meaningful (for 
> example, represent a special kind of extension through the namespace 
> URI). but then how would you map this to the equivalent JSON? you'd 
> have to define a generic namespace mapping from XML into JSON, or 
> something specific for our format, and both options are not very 
> appealing.
>
My understanding was that the JSON model would be primary; hence the XML 
version would not be arbitrary XML, but only an XML version of whatever 
was expressible in the JSON syntax. So there'd be no need for anything 
complicated.

---

From: Conal Tuohy <[email-masked]>
Date: Tue, 08 Jan 2013 08:25:11 +1000

On 07/01/13 23:09, Erik Wilde wrote:
> representation (specifically, JSON and XML), and you don't want to be 
> in the business of inventing namespaces in JSON, then avoiding 
> namespaces in XML may be the best way to go. 
Indeed, and I'd agree with that syllogism, and with the first premise, 
but not the second.

In fact the informal JSON schema for http-problem already has invented a 
quasi-namespace feature - "describedBy". It would be only a small 
stretch to allow for an http-problem to include multiple "describedBy" 
links, each qualifying a particular set of properties. That would be my 
preferred solution.
> it still looks wrong to me, from the XML point of view, but from he 
> "let's reuse the same model in JSON and XML" view, maybe it's the best 
> possible way to go.
>
I presented a couple of use cases for namespaced properties which I 
think show that there's some value in having namespaces in the 
underlying model (i.e. for both XML and JSON). Do you have any comment 
on those?