Subject: [apps-discuss] Questions about Structured Syntax Suffixes (SSS)

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 May 2012 11:35:37 +1000

I apologise if this has already been discussed, but this list has become nearly unreadable recently.

<http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-01.txt> motivates SSS with:

"""
2.  When to Use these Structured Syntax Suffixes

   Each of the Structured Syntax Suffixes defined in this document is
   appropriate for use when the media type identifies the semantics of
   the protocol payload.  That is, knowing the semantics of the specific
   media type provides for more specific processing of the content than
   that afforded by generic processing of the underlying representation.

   At the same time, using the suffix allows receivers of the media
   types to do generic processing of the underlying representation in
   cases where

      * they do not need to perform special handling of the particular
      semantics of the exact media type, and,

      * there is no special knowledge needed by such a generic processor
      in order to parse that underlying representation other than what
      would be needed to parse any example of that underlying
      representation.
"""

Question: Is this actually useful in practice? I.e., what are the real-world use cases for SSS?

We started this experiment with +xml, and I'm not aware of much software that uses that suffix to great advantage (please educate me if I'm overlooking something).

One might imagine an editor to hint the convention used for the content, so that it can (for example) use an XML or JSON mode, but editors key off of filename extensions and magic, not media types.

What else is there?

I'm not debating that humans might find it satisfying to see the underlying formatting convention / metamodel surfaced in the media type, but I haven't seen much discussion of how machines will use this.

Question: So, if we were to invent a "profile" of JSON or XML that, for example, added linking conventions, maybe some other syntactic sugar, would that be suitable for registration as a suffix?

Question: Several of the proposed suffixes are effectively alternate encodings for the same data (e.g., fastinfoset, xml, wbxml), or very similar data. When I register a new media type, am I expected to register all of them?

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 24 May 2012 11:39:54 +0100

Mark Nottingham writes:

> We started this experiment with +xml, and I'm not aware of much
> software that uses that suffix to great advantage (please educate me
> if I'm overlooking something).

Good question!  I did a quick check, and the four browsers I looked at
did _not_ treat material served as application/foo+xml as XML (unless
its URI ended with ".xml").

So _currently_ (aside from application/html+xml, which is recognised
as a unit, not specifically as allowing generic XML processing because
of the '+xml') the suffix serves only, as you suggest, as
human-readable confirmation of expectations.

_But_ I think there is at least a potential upside going forward, in
that as we see both ...+xml and ...+json variants of particular types,
I _would_ expect software to dispatch on this information, rather than
sniffing.  Or, to turn that around, if we _don't_ support SSS, we are
in practice requiring applications to sniff.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 May 2012 20:57:59 +1000

> its URI ended with ".xml").

Ah, that.

> in practice requiring applications to sniff.

What software? If it knows about the specific format -- whatever convention is used -- it's not necessary to have a convention. The convention is only good for software that DOESN'T know about the specific semantics/syntax of the format in use, but can derive some value from knowing a few generic conventions about it.

The only one I can come up with is a generic test tool, like the one that I run at <http://redbot.org/>; with this sort of information, it'd be able to colourise the syntax of a few more formats that pass through it. 

To me, that's pretty thin justification; I'm not asking for this, and I run one of these tools!

What I'm concerned about is that this may encourage people to register both XML and JSON variants of a format -- in fact, I suspect that this is part of the underlying motivation. I've already given my thoughts about that here <http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide>.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 May 2012 13:08:33 +0200

On 2012-05-24 03:35, Mark Nottingham wrote:
> ...

XMLHttpRequest does.

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 24 May 2012 12:08:39 +0100

Mark Nottingham writes:

> HST wrote:
>> . . .
> What software? If it knows about the specific format -- whatever
> convention is used -- it's not necessary to have a convention.

Howzat?  If I support application/foo, and I do a GET for a URI I
expect to yield such a payload, I need _some_ way of telling
whether the results use XML or JSON.  Either I sniff, or I have
information in the media type.  The latter has the advantage that if
I'm old-fashioned, and only support the XML variant, I can use a
well-understood mechanism to _ask_ for that variant, i.e. an Accept:
request header.

This also points towards another (putative, eventual) benefit --
suppose we do end up in a world with a number of formats which are
manifested in both +xml and +json variants -- I would hope/expect that
at least toolkits, and with luck browsers themselves, would offer API
wrappers around XMLHttpRequest that automagically parsed responses
based on + suffixes and handed over either JS or DOM objects as
appropriate.

ht

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 May 2012 21:12:51 +1000

>> We started this experiment with +xml, and I'm not aware of much software that uses that suffix to great advantage (please educate me if I'm overlooking something).

Details...?

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 24 May 2012 12:14:17 +0100

> based on + suffixes and handed over either JS or DOM objects as

Sorry, the above as written is of course contradictory -- what I
should have said was "would offer a variant of XMLHttpRequest".

ht

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 May 2012 13:18:51 +0200

>>> We started this experiment with +xml, and I'm not aware of much software that uses that suffix to great advantage (please educate me if I'm overlooking something).

<http://www.w3.org/TR/XMLHttpRequest/#response-entity-body-0>:

"2. If final MIME type is not null, text/html, text/xml, 
application/xml, or does not end in +xml, return null and terminate 
these steps."

Best regards, Julian