- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 13 Jun 2008 00:04:08 +0000
- To: public-sml@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5546 --- Comment #5 from Kumar Pandit <kumarp@microsoft.com> 2008-06-13 00:04:08 --- Here is the email I had sent to public-sml regarding this topic: ------------------ From: Kumar Pandit Sent: Tuesday, April 29, 2008 3:48 PM To: public-sml@w3.org Cc: Kumar Pandit Subject: RFC 2557 & SML-IF During the last conf call, I volunteered to send notes on comparison between RFC 2557 & SML-IF and start an email thread for discussing the issue. This was recorded as action-item# 182. I studied RFC 2557 and some other RFCs referenced by this RFC to see how it compares to SML-IF. I found several incompatibilities that make RFC 2557 based packaging not suitable for representing an SML model and the associated metadata/semantics. I also searched for an XML based packaging RFC but I didn’t find one. Here is a summary of what I found. RFC 2557 (MIME Encapsulation of Aggregate Documents) is aimed at e-mail transfer of multi-resource HTML multimedia documents. The RFC mentions that the conventions defined in that RFC can also be used for self-contained multi-resource HTML multimedia documents retrieved by other protocols such as HTTP and FTP. The root resource in such a document must be of type text/html. RFC 2557 allows hierarchical packaging of entities for which a mime type is defined. It also allows encoding some or all of the body parts as base64. In order to simulate SML-IF like structure using RFC 2557, one may package XML documents inside an html root resource. That is, something like below: 1. root: text/html a. metadata (such as rule/schema bindings, etc.): multipart/related b. definition documents: multipart/related c. instance documents: multipart/related Each of the multipart/related part above (1b/1c) can then contain a collection of documents some of which may be encoded as base64. However, this representation is simplistic at best. It does not permit many higher level abstractions and some semantic restrictions that are currently used in SML-IF. RFC 2557 does not permit URIs that cross multipart/related boundary. Thus items such as those defined in the rule/schema bindings will not be allowed to refer to documents in 1.b/1.c. One solution may be to put all items in 1.a/1.b/1.c into a single multipart/related group but it has problems of its own. RFC 2557 mandates that each body part must have only one URI. SML-IF allows multiple aliases per document. SML-IF allows different handling of URI references depending upon whether a schema document retrieval is involved. For example, if the target document of an SML reference is not in the model then that reference is deemed unresolved. On the other hand, an implementation is allowed to fetch a schema document from outside the model in certain cases. This type of target specific URI reference resolution is not permitted in RFC 2557. It treats resolution of all URI references in the same way. There is no way to override this. In RFC 2557, URI reference resolution always has a baseURI (either explicitly specified or the implicit “thismessage:/”). This means that certain invalid-model cases in SML-IF cannot be represented using RFC 2557. A document formatted according to RFC 2557 cannot be validated against XML schema. Body parts of an RFC 2557 document can be semantically extended using the “start-info” parameter. This parameter can have any free form value. SML-IF defines extension points using XML schema wildcards. The extension values can be validated against a schema. In SML-IF, reference resolution behavior is governed by the category of the target. For example, an SML reference pointing to a schema document must be treated as unresolved. In RFC 2557 there is no provision to define target category specific URI reference resolution. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 13 June 2008 00:04:44 UTC