Re: [invisibleXML/ixml] Media type? (#6)

----- Forwarded message -----
From: Steven Pemberton <steven.pemberton@cwi.nl>
To: invisibleXML/ixml <reply+ACNIXL6UVIYXUN4IVB3Q2AF7SWTCXEVBNHHDUAL3FY@reply.github.com>, "C. M. Sperberg-McQueen" <notifications@github.com>, invisibleXML/ixml <ixml@noreply.github.com>
Cc: Comment <comment@noreply.github.com>
Subject: Re: [invisibleXML/ixml] Media type? (#6)
Date: Tue Jan 11 2022 12:12:10 GMT+0100 (Central European Standard Time)


This reply is part of the action I took at the 2021-11-09 meeting.


>If memory serves, Steven's talk on Invisible XML at Balisage 2013 included a fairly substantial discussion of how to use HTTP headers to 
> associate ixml grammars with data being served on a web server. Either memory is deceptive, or Steven talked about it in his slides more 
> than he wrote about it in the paper; the paper in the proceedings deals with the topic very briefly, suggesting that an HTTP server might 
> serve an ixml-parseable CSS file with the header
> 
>     content-type: application/xml-invisible; syntax=http://example.com/syntax/css
> 
> as well as with the conventional header for CSS files.


The discussion was not at all substantial, but a suggestion of how to deliver a document so that it gets treated as XML, even though it isn't XML.


From the first paper:
<<<
To deliver a source document to be parsed by our system, we can use a media type that supplies a reference to the required syntax description. For instance:


   application/xml-invisible; syntax=http://example.com/syntax/css


Clearly a system can cache well-known syntax descriptions.
>>>


> Ought the 1.0 spec to say something about this topic?


I'm not yet convinced that it ought, especially since registering a media type is a time-consuming activity in my experience. We could later produce a separate document on "Serving documents meant to be processed by an ixml processor".


> Should the spec require or recommend a specific media type?


Note that the original paper uses the media type for serving *documents*, not for ixml, so that the (non-XML) document can be treated as XML. This means that the spec cannot recommend specific media types (except possibly for ixml itself, which seldom needs to be served anyway).


> If so, should it be a subtype of application or of text?


This is a bug (IMHO) in the media types definition: as with XML, it really ought to be text, but the default character encoding for text/* is ASCII. A fix for this would be to define a new top-level type e.g. document/* which used UTF-8 as the default encoding. But I doubt we want to take that fight on. So then we would have to use


 text/ixml; charset="utf-8"


just as XML does.


Additionally we need a required parameter, 


 syntax=<uri>


that specifies which grammar to use to process the document being served. This is a URI that in principle says where you can obtain the ixml grammar:


 text/ixml; charset="utf-8"; syntax="https://invisiblexml.org/ixml.ixml"


However, it can be construed as an identifier that identifies the syntax without you necessarily having to go to that location to retrieve it (and in the case of ixml shouldn't retrieve, otherwise you'll end up in a retrieval loop).


> Is there an interoperable way to associate ixml grammars with specific well known 
> media types (like CSS) that does not depend on either (a) the owner of the server 
> where the CSS file resides, or (b) the creator of the particular ixml processor we 
> are using?


I think the answer to both is "yes"; see above.


Summary:


 text/ixml; charset="utf-8"; syntax="<uri>"


Steven

On Tuesday 09 November 2021 01:47:39 (+01:00), C. M. Sperberg-McQueen wrote:



At the community group meeting of 12 October, Steven Pemberton took an action to draft a media types proposal for the spec. In the agenda, for tracking purposes it's action 2021-10-001.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.