Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OF1mqt054427 for ; Thu, 24 Jul 2003 08:01:48 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OF1mFD054426 for ietf-xml-mime-bks; Thu, 24 Jul 2003 08:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from vorpal.notabug.com (qmailr@vorpal.notabug.com [63.149.73.20]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6OF1kqt054420 for ; Thu, 24 Jul 2003 08:01:46 -0700 (PDT) (envelope-from me@aaronsw.com) Received: (qmail 447 invoked from network); 24 Jul 2003 15:01:47 -0000 Received: (ofmipd 12.207.74.63); 24 Jul 2003 15:01:25 -0000 Date: 24 Jul 2003 10:01:47 -0500 Message-Id: From: "Aaron Swartz" To: ietf-types@iana.org Cc: ietf-xml-mime@imc.org, www-rdf-comments@w3.org Mime-Version: 1.0 (Apple Message framework v578) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Subject: for review: RDF/XML Media Type registration draft X-Mailer: Apple Mail (2.578) Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In accordance with section 2.3.1 of RFC 2048, I'd like your comments and feedback on our draft registration of a media type for the W3C's RDF/XML format. The Internet-Draft is at: http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml- mediatype-02.txt or, more permanently, http://www.aaronsw.com/2002/draft-swartz-rdfcore-rdfxml-mediatype -02.html (or .txt or .xml) RFC 2048 recommends comments "on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations." I'll respond to feedback for two weeks and on August 8th I'll release an updated Internet-Draft folding in all the changes. Thanks, -- Aaron Swartz: http://www.aaronsw.com/ww Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IIW0qt014407 for ; Fri, 18 Jul 2003 11:32:00 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IIW0On014406 for ietf-xml-mime-bks; Fri, 18 Jul 2003 11:32:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from usmailrelay.bea.com (sj-ez-63-96-163-59.bea.com [63.96.163.59] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IIVxqt014395 for ; Fri, 18 Jul 2003 11:31:59 -0700 (PDT) (envelope-from mark.nottingham@bea.com) Received: from san-francisco.bea.com (san-francisco.bea.com [10.32.0.10]) by usmailrelay.bea.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h6IIW1E22354 for ; Fri, 18 Jul 2003 11:32:01 -0700 (PDT) Received: from mnotlaptop (sj-iz-172-17-30-72.bea.com [172.17.30.72]) by san-francisco.bea.com (8.9.3+Sun/8.9.1) with SMTP id LAA13594 for ; Fri, 18 Jul 2003 11:32:00 -0700 (PDT) Message-ID: <005f01c34d5a$de302b40$481e11ac@mnotlaptop> From: "Mark Nottingham" To: Subject: Alternate serializations of XML? Date: Fri, 18 Jul 2003 11:31:41 -0700 Organization: BEA Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I haven't tracked the list closely, so apologies if this is a FAQ. It appears that we're likely to see at least one alternate serialization of the XML infoset in the not-too-distant future. For example, there is active work (summarized at [1]) in ITU-T and ISO to define a few different mappings of it to XML. Without debating how useful these encodings will be, I wonder how they'll be rationalized with the media type system. I see three options: a) Define a single media type (e.g., "application/xml-asn1") to identify all such formats (which seems to fall in the same pit as text/xml and application/xml). b) For every format, define a media type for each encoding (e.g., "application/svg+xml" and "application/svg+asn1"). However, this requires multiple registrations, and may be bad for interoperability if encodings aren't registered. Doesn't seem scalable. c) Describe it as an encoding that's orthoganal to the media type; e.g., much as a MIME content-transfer-encoding or HTTP content-coding. Format-specific encodings are unusual, to say the least, but I can't find anything that prohibits them. Are there other options? 1. http://asn1.elibel.tm.fr/xml/ -- Mark Nottingham Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h671l0qt002738 for ; Sun, 6 Jul 2003 18:47:00 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h671l07s002737 for ietf-xml-mime-bks; Sun, 6 Jul 2003 18:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h671kwqt002732 for ; Sun, 6 Jul 2003 18:46:58 -0700 (PDT) (envelope-from mbaker@markbaker.ca) Received: (from mbaker@localhost) by markbaker.ca (8.11.6/8.11.6) id h671qFR05928; Sun, 6 Jul 2003 21:52:15 -0400 Date: Sun, 6 Jul 2003 21:52:15 -0400 From: Mark Baker To: ietf-types@alvestrand.no, ietf-xml-mime@imc.org Subject: Re: Request for advice: sbml+xml Media Type Message-ID: <20030706215215.D1116@www.markbaker.ca> References: <1057375320.3f0644587f235@webmail.nethere.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1057375320.3f0644587f235@webmail.nethere.net>; from bkovitz@caltech.edu on Fri, Jul 04, 2003 at 08:22:00PM -0700 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Ben, On Fri, Jul 04, 2003 at 08:22:00PM -0700, Ben Kovitz wrote: > 1. Would it be a bad idea if we used RFC3236 (The > application/xhtml+xml Media Type) as a model for the document w > write? I'm hoping that we don't need to explain the full > semantics of SBML in the RFC, since there are already some > weighty papers that do that (referenced above). At only 8 pages, > RFC3236 seems like a model of simplicity and clarity that we > would like to emulate. I'm not sure I'd agree, but thanks! > Or is it possible to get even simpler? > Some of the docs I found for XML MIME media types seemed to do > little more than list the name of the type and who submitted it. There's a continuum, of course. For RFC 3236, Peter and I went out of our way to include all the pertinent information that we felt was required by the media type registration process. The problem with this, of course, is that some information in the specification needs to be duplicated in the registration. Luckily, this issue was recognized by the IETF, and more recent W3C-initiated media type registrations are using a "shell" registration document which permits the IANA media type registration form to be included within the W3C-maintained specification. See, for example, the SOAP registration; http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt Unfortunately for you, I don't think this would apply, as I believe this arrangement is fairly unique between the W3C and IETF, or at least between the IETF and other similarly trusted organizations. > 2. We are thinking of including required parameters of "level" > and "version". Anything to watch out for here? Is this a wrong > idea? SBML has multiple levels to enable different simulation > tools to interoperate at different levels of complexity and > sophistication. Each level can come in different versions. More > levels are planned. In my observation, these rarely work out as extensibility mechanisms. text/html used to have one ("level"), and it wasn't used, so wasn't included in RFC 2854. application/xhtml+xml has one ("profile"), but it's there for a single purpose only; to help WAP apps distinguish between XHTML Basic and XHTML 1.0. I'm not aware of anybody using it for other reasons. You might want to consider whether prescribing sufficiently extensible processing behaviour - such that "higher level" (more complex) content may be properly processed by a "lower level" processor - would be adequate for your needs. Feel free to contact me off-line if you'd like some advice on how that might be done. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h655Zpqt030585 for ; Fri, 4 Jul 2003 22:35:51 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h655ZpaZ030584 for ietf-xml-mime-bks; Fri, 4 Jul 2003 22:35:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mercury.ccil.org (mercury.ccil.org [192.190.237.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h655Zoqt030579 for ; Fri, 4 Jul 2003 22:35:50 -0700 (PDT) (envelope-from cowan@mercury.ccil.org) Received: from cowan by mercury.ccil.org with local (Exim 3.35 #1 (Debian)) id 19YffU-00011B-00; Sat, 05 Jul 2003 01:33:04 -0400 Date: Sat, 5 Jul 2003 01:33:04 -0400 To: Ben Kovitz Cc: ietf-types@alvestrand.no, ietf-xml-mime@imc.org Subject: Re: Request for advice: sbml+xml Media Type Message-ID: <20030705053304.GA3320@mercury.ccil.org> References: <1057375320.3f0644587f235@webmail.nethere.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1057375320.3f0644587f235@webmail.nethere.net> User-Agent: Mutt/1.3.28i From: John Cowan Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ben Kovitz scripsit: > 1. Would it be a bad idea if we used RFC3236 (The > application/xhtml+xml Media Type) as a model for the document w > write? I'm hoping that we don't need to explain the full > semantics of SBML in the RFC, since there are already some > weighty papers that do that (referenced above). At only 8 pages, > RFC3236 seems like a model of simplicity and clarity that we > would like to emulate. Or is it possible to get even simpler? > Some of the docs I found for XML MIME media types seemed to do > little more than list the name of the type and who submitted it. The important point is that RFCs are rock-stable; they can be updated or replaced by other RFCs, but not changed in themselves. Any documents they make normative reference to have to be similarly stable. Note that you don't have to write an RFC in full formality to do the job here, since you are using an existing top-level type. > 2. We are thinking of including required parameters of "level" > and "version". Anything to watch out for here? Is this a wrong > idea? SBML has multiple levels to enable different simulation > tools to interoperate at different levels of complexity and > sophistication. Each level can come in different versions. More > levels are planned. If these already exist in the XML, then there is no need to make them required parameters. If they don't exist in the XML, I suggest you make them exist there. -- First known example of political correctness: John Cowan "After Nurhachi had united all the other http://www.reutershealth.com Jurchen tribes under the leadership of the http://www.ccil.org/~cowan Manchus, his successor Abahai (1592-1643) jcowan@reutershealth.com issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all _The Languages of China_ to be called Manchus." Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h653Lwqt028184 for ; Fri, 4 Jul 2003 20:21:58 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h653LwIV028183 for ietf-xml-mime-bks; Fri, 4 Jul 2003 20:21:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail-3.nethere.net (mail-3.nethere.net [66.63.128.72]) by above.proper.com (8.12.9/8.12.8) with SMTP id h653Lvqt028178 for ; Fri, 4 Jul 2003 20:21:57 -0700 (PDT) (envelope-from bkovitz@caltech.edu) Received: (qmail 27975 invoked from network); 5 Jul 2003 03:22:00 -0000 Received: from webmail-1.nethere.net (localhost [66.63.128.78]) by mail-3.nethere.net with SMTP; 5 Jul 2003 03:22:00 -0000 (envelope-sender ) Received: from dhcp-193.cds.caltech.edu (dhcp-193.cds.caltech.edu [131.215.42.193]) by webmail.nethere.net (IMP) with HTTP for ; Fri, 4 Jul 2003 20:22:00 -0700 Message-ID: <1057375320.3f0644587f235@webmail.nethere.net> Date: Fri, 4 Jul 2003 20:22:00 -0700 From: Ben Kovitz To: ietf-types@alvestrand.no, ietf-xml-mime@imc.org Subject: Request for advice: sbml+xml Media Type MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Originating-IP: 131.215.42.193 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I work on SBML (Systems Biology Markup Language) at Caltech. We are thinking of proposing a new XML MIME media type. When learning about the process for getting a new IETF-tree media type approved, I was strongly advised to consult the members of the ietf-types and ietf-xml-mime discussion lists for advice before diving in. So here I am. I'll appreciate any advice you can give me, especially any that saves us from making some stupid mistakes that the biological modeling community will regret for years to come. Please forgive me if I reveal my ignorance in some questions below. First, a little background. SBML is an XML format for representing systems of biochemical reactions. Making it a MIME media type would enable browser-based simulation tools to conveniently download, run, and edit models. Work is now beginning on a web infrastructure to make it easy for biological researchers to share models on the web, download models used in published papers, etc. Two "levels" of SBML have been defined so far. Specifications, including the XML schemas, are at: http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-1-version-2/sbml-level-1.pdf http://www.sbw-sbml.org/sbml/docs/papers/sbml-level-2-version-1/sbml-level-2.pdf We are thinking that the ideal name would be either: application/sbml+xml or: model/sbml+xml Now, here are a few questions. 1. Would it be a bad idea if we used RFC3236 (The application/xhtml+xml Media Type) as a model for the document w write? I'm hoping that we don't need to explain the full semantics of SBML in the RFC, since there are already some weighty papers that do that (referenced above). At only 8 pages, RFC3236 seems like a model of simplicity and clarity that we would like to emulate. Or is it possible to get even simpler? Some of the docs I found for XML MIME media types seemed to do little more than list the name of the type and who submitted it. 2. We are thinking of including required parameters of "level" and "version". Anything to watch out for here? Is this a wrong idea? SBML has multiple levels to enable different simulation tools to interoperate at different levels of complexity and sophistication. Each level can come in different versions. More levels are planned. 3. Is it completely stupid to even consider model/sbml+xml? The other model/ media types have been for spatial models. SBML is primarily used for spatial models of reactions that occur within biological cells, and has some notions of spatial relation, but an SBML model does not necessarily have the minimum 3 orthogonal dimensions specified in RFC2077. We're wondering if SBML is still within the spirit of the model/ top-level content type, though. RFC2077 speaks of economic models, behavioral models, and so on, and seems to encourage a situation where modeling tools might work successfully on models from radically different domains. 4. Any other advice you'd care to offer? Thanks in advance for your assistance, Ben -- Ben Kovitz Systems Biology Workbench (SBW) Development Group, Caltech http://www.sbw-sbml.org bkovitz at caltech.edu