Subject: RE: versioning and extensibility with OWL - msg#00019

Previous Message by Date: click to view message preview

Fw: Revising RFC 3023

Forwarded by MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxx> ----------------------- Original Message ----------------------- From: MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxx> To: ietf-xml-mime@xxxxxxx Date: Sun, 25 Jul 2004 22:43:07 +0900 Subject: Revising RFC 3023 ---- I am forwarding an e-mail from Noah Mendelsohn. It contains some suggestions I got from Noah in private discussion at IBM. I have his permission to circulate publicly. Cheers, MURATA Makoto -------------------------------------------- Murata Makoto writes: >> It is true that RFC 3023 does not reference to XML 1.1, although I >> do not see anything specific to XML 1.0 (with the exception of >> security concerns caused by C0 control functions).. The references I found in 3023 are: "The World Wide Web Consortium has issued Extensible Markup Language (XML) 1.0 (Second Edition)[XML]. " "Published specification: Extensible Markup Language (XML) 1.0 (Second Edition)[XML]." and more specifically all the examples which show: Content-type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8"?> and so on. I now see that all of this may have just been intended as the then-latest forms, but I read them as specific instructions for use of xml 1.0 as the proper form of application/xml. So, at the very least, I think it would be helpful to be more explicit in future replacements or updates to 3023. >> I plan to reference to XML 1.1 as well as XML 1.0 in the next I-D, >> which is expected to supsersede RFC 3023. I'm torn about this. In the specific case of SOAP, our recommendation says that implementations of our HTTP bindings MUST be capable of sending and receiving in the media-type "application/soap+xml", which we normatively base on 3023 and application/xml. In making this statement, I doubt that most members of the working group realized that they might have been introducing an open-ended need to conform to all future versions of XML, including those that would allow previously-illegal control character content. Maybe if we'd known such an XML 1.1 was coming we would have and should have put in such a requirement to support both: my point is just that I don't think we did so consciously. I have openned a discussion of all this on the distApp mailing list [1], and will in a minute send an update pointing out the tie-in to RFC 3023. I will cc: you on that update. distApp is a public mailing list, and you are most welcome to join in. For what it's worth, SOAP puts a tremendous emphasis on interoperability, so saying that two conforming implemenations of this binding can disagree about what's legal in the preferred form of messages is at least a bit troubling. The original design point was: if you conform, you can communicate. Even if 3023 is to support any version of XML, we in SOAP may be able to fix things with a clarification to our recommendation. It so happens that we already allow use of any other media type, it's just that we make clear that application/soap+xml is the lingua franca. Use something else and it will only work if the recipient agrees. I suspect we'll wind up saying: "application/xml with xml version 1.0 is the lingua franca, you can use other media types or application/soap+xml with later versions of XML, but only if the recipient supports them." The control character business is a bigger mess for us I think, as we have a quite strong rule that the constraints on SOAP envelopes are the same everywhere, and they are basically what you'd expect from Infoset (and implicitly XML 1.0). Note that such envelopes are by definition synthetic Infosets. XML 1.1 suggests that, regardless of how you serialize the message on each hop, there is a question as to whether in the abstract the new control characters are allowed in the envelope infosets. If so, then such messages cannot transit hops implemented with already deployed software, and that's very troubling to me. >> If you have any comments about how these two specs should be >> referenced, please let me know. I even think that there should be a >> W3C guideline about references to XML 1.0 and XML 1.1. Does the XML >> Core WG have some recommendations? I'm not sure I have a carefully considered opinion, but what about the following as a starting point for discussion? Very Rough Draft of Proposed W3C policy: "The publication of XML 1.1 highlights the fact that evolved versions of XML may change both the serialized form of an XML document and the content representable in such a document. In the case of XML 1.1, for example, certain control characters disallowed by XML 1.0 were added to the Char production. Accordingly, W3C recommends that: * Every recommendation or other publication that makes normative reference to XML as a serialized document format should make clear which versions of XML it supports, and in particular whether it allows for support of potential variants to be published in the future. * When calling for serialization of data into an XML document, such recommendations SHOULD appeal to the conventions of the supported versions of XML regarding proper use of the XML declaration (for example, the XML 1.1 recommendation suggests use of version="1.1" only for those documents which would not be correctly represented as version="1.0".) * Recommendations should similarly clarify any dependencies on particular versions of XML regarding the abstract content of data modeled as XML. For example, a recommendation based on the Infoset, XPath data model, DOM, SAX, etc. SHOULD indicate whether the control characters introduced by XML 1.1 are allowed in element content, SHOULD indicate whether potential future changes to XML constructs such (e.g. a purely hypothetical future change to the set of legal XML name characters) would be supported, and so on. " In the case of future versions of RFC 3023, I think the most appropriate course might be to say: "application/xml is to be used with any W3C Recommendation-level version of XML as identified in the version specification of the XML declaration. When no such declaration is present, XML 1.0 is assumed. In all examples herein where a specific version such as version="1.0" is shown, it is understood that other versions may also be used, providing the content does indeed conform to the specified version of the XML Recommendation. Specifications and recommendations based on or referring to this RFC SHOULD indicate any limitations on the particular versions of XML to be used. For example, a particular specification might indicate: "content MUST be represented using media-type application/xml, and the document must either (a) carry an xml declaration specifying version="1.0" or (b) omit the xml declaration, in which case per the XML recommendation the version defaults to 1.0" Does that seem like a reasonable start? [1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0006.html --------------------- Original Message Ends -------------------- -- MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxx> --------------------- Original Message Ends --------------------

Next Message by Date: click to view message preview

RE: XML Extensibility and versioning

Hi Al, I've recently been appointed an editor of the finding on TAG issue 41. I'm also the author of the article that is extensively referenced in the article you refer to. The original TAG finding did have material on using XML Schema to enable compatible evolution, but this was expunged late last year from the general TAG finding. I don't know of any reason why we won't be producing a finding on using various schema languages and techniques to achieve evolution. I plan on incorporating the article's observations as much as possible in said TAG finding. I particularly like the use of the delimiter technique for enabling compatible schema evolution, in many cases it's cleaner than the extension element technique I came up with. I'm less sure of the rules around when to use multiple namespaces for versioning. I'm very interested in your experience with the various aspects of extensibility that are outlined in my xml.com article, Dare's xml.com article, and the TAG finding. Cheers, Dave -----Original Message----- From: www-tag-request@xxxxxx [mailto:www-tag-request@xxxxxx] On Behalf Of Al Gilman Sent: Thursday, July 22, 2004 8:46 AM To: www-tag@xxxxxx Cc: Dominique Hazaël-Massieux Subject: Fwd: XML Extensibility and versioning Does this relate to the XMLVersioning-41 issue? http://www.w3.org/2001/tag/issues.html?type=1#XMLVersioning-41 Al >From: Dominique Hazaël-Massieux <dom@xxxxxx> >To: www-qa@xxxxxx >Date: Thu, 22 Jul 2004 17:18:29 +0200 >Subject: XML Extensibility and versioning >X-Archived-At: http://www.w3.org/mid/1090509509.4569.1778.camel@stratustier > >XML.com published an article from Dare Obasanjo [1] yesterday, about XML >Extensibility and Versioning; I've only skimmed through it, but it seems >to touch on several of the points that SpecGL tries to address in >extension and deprecation applied to the specific case of XML languages. > >It would be great if someone had the time to look further on whether >some of the points in the article should inspire new good practices or >techniques in SpecGL; I may end up doing it next week, but would love to >see contributions from others :) > >Dom > >1. http://www.xml.com/pub/a/2004/07/21/design.html >-- >Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/ >W3C/ERCIM >mailto:dom@xxxxxx > > >Content-Type: application/pgp-signature; name=signature.asc >Content-Description: Ceci est une partie de message > numériquement signée. >

Previous Message by Thread: click to view message preview

Fw: Revising RFC 3023

Forwarded by MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxx> ----------------------- Original Message ----------------------- From: MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxx> To: ietf-xml-mime@xxxxxxx Date: Sun, 25 Jul 2004 22:43:07 +0900 Subject: Revising RFC 3023 ---- I am forwarding an e-mail from Noah Mendelsohn. It contains some suggestions I got from Noah in private discussion at IBM. I have his permission to circulate publicly. Cheers, MURATA Makoto -------------------------------------------- Murata Makoto writes: >> It is true that RFC 3023 does not reference to XML 1.1, although I >> do not see anything specific to XML 1.0 (with the exception of >> security concerns caused by C0 control functions).. The references I found in 3023 are: "The World Wide Web Consortium has issued Extensible Markup Language (XML) 1.0 (Second Edition)[XML]. " "Published specification: Extensible Markup Language (XML) 1.0 (Second Edition)[XML]." and more specifically all the examples which show: Content-type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8"?> and so on. I now see that all of this may have just been intended as the then-latest forms, but I read them as specific instructions for use of xml 1.0 as the proper form of application/xml. So, at the very least, I think it would be helpful to be more explicit in future replacements or updates to 3023. >> I plan to reference to XML 1.1 as well as XML 1.0 in the next I-D, >> which is expected to supsersede RFC 3023. I'm torn about this. In the specific case of SOAP, our recommendation says that implementations of our HTTP bindings MUST be capable of sending and receiving in the media-type "application/soap+xml", which we normatively base on 3023 and application/xml. In making this statement, I doubt that most members of the working group realized that they might have been introducing an open-ended need to conform to all future versions of XML, including those that would allow previously-illegal control character content. Maybe if we'd known such an XML 1.1 was coming we would have and should have put in such a requirement to support both: my point is just that I don't think we did so consciously. I have openned a discussion of all this on the distApp mailing list [1], and will in a minute send an update pointing out the tie-in to RFC 3023. I will cc: you on that update. distApp is a public mailing list, and you are most welcome to join in. For what it's worth, SOAP puts a tremendous emphasis on interoperability, so saying that two conforming implemenations of this binding can disagree about what's legal in the preferred form of messages is at least a bit troubling. The original design point was: if you conform, you can communicate. Even if 3023 is to support any version of XML, we in SOAP may be able to fix things with a clarification to our recommendation. It so happens that we already allow use of any other media type, it's just that we make clear that application/soap+xml is the lingua franca. Use something else and it will only work if the recipient agrees. I suspect we'll wind up saying: "application/xml with xml version 1.0 is the lingua franca, you can use other media types or application/soap+xml with later versions of XML, but only if the recipient supports them." The control character business is a bigger mess for us I think, as we have a quite strong rule that the constraints on SOAP envelopes are the same everywhere, and they are basically what you'd expect from Infoset (and implicitly XML 1.0). Note that such envelopes are by definition synthetic Infosets. XML 1.1 suggests that, regardless of how you serialize the message on each hop, there is a question as to whether in the abstract the new control characters are allowed in the envelope infosets. If so, then such messages cannot transit hops implemented with already deployed software, and that's very troubling to me. >> If you have any comments about how these two specs should be >> referenced, please let me know. I even think that there should be a >> W3C guideline about references to XML 1.0 and XML 1.1. Does the XML >> Core WG have some recommendations? I'm not sure I have a carefully considered opinion, but what about the following as a starting point for discussion? Very Rough Draft of Proposed W3C policy: "The publication of XML 1.1 highlights the fact that evolved versions of XML may change both the serialized form of an XML document and the content representable in such a document. In the case of XML 1.1, for example, certain control characters disallowed by XML 1.0 were added to the Char production. Accordingly, W3C recommends that: * Every recommendation or other publication that makes normative reference to XML as a serialized document format should make clear which versions of XML it supports, and in particular whether it allows for support of potential variants to be published in the future. * When calling for serialization of data into an XML document, such recommendations SHOULD appeal to the conventions of the supported versions of XML regarding proper use of the XML declaration (for example, the XML 1.1 recommendation suggests use of version="1.1" only for those documents which would not be correctly represented as version="1.0".) * Recommendations should similarly clarify any dependencies on particular versions of XML regarding the abstract content of data modeled as XML. For example, a recommendation based on the Infoset, XPath data model, DOM, SAX, etc. SHOULD indicate whether the control characters introduced by XML 1.1 are allowed in element content, SHOULD indicate whether potential future changes to XML constructs such (e.g. a purely hypothetical future change to the set of legal XML name characters) would be supported, and so on. " In the case of future versions of RFC 3023, I think the most appropriate course might be to say: "application/xml is to be used with any W3C Recommendation-level version of XML as identified in the version specification of the XML declaration. When no such declaration is present, XML 1.0 is assumed. In all examples herein where a specific version such as version="1.0" is shown, it is understood that other versions may also be used, providing the content does indeed conform to the specified version of the XML Recommendation. Specifications and recommendations based on or referring to this RFC SHOULD indicate any limitations on the particular versions of XML to be used. For example, a particular specification might indicate: "content MUST be represented using media-type application/xml, and the document must either (a) carry an xml declaration specifying version="1.0" or (b) omit the xml declaration, in which case per the XML recommendation the version defaults to 1.0" Does that seem like a reasonable start? [1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0006.html --------------------- Original Message Ends -------------------- -- MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxx> --------------------- Original Message Ends --------------------

Next Message by Thread: click to view message preview

Plan for TAG issue 41

Over the past half year, I’ve been executing on a rough mental plan for the next version of the TAG finding on issue 41.  I’ve been steadily creating material for inclusion in the finding.  I’ve run the plan by Norm and he agrees with it.  The plan, including references, is listed below.   Overall The options and trade-offs for versioning are not clearly enough articulated.  For example, the problems of using a new namespace for any additional version information are not clear enough.  Design for transformation of vX data into vY data (substitutability) has a number of options that need to be listed and described.  An examination of protocol extensibility, that is the addition/deletion of operations, and compatibility of groups of operations (interfaces) provides for versioning and extensibility beyond just formats.   I’d like to take the xml schema example that was in the first draft of the finding and move it, as well as providing for various languages – XML Schema, RelaxNG, and RDF/OWL – into an “Extensibility and versioning using various languages” document.  Dare Obasanjo’s delimiter technique should be added to this doc.   And finally, the issue of versioning of interfaces using WSDL will be introduced.   Details:   In all documents: -          change examples to “name” example – first,last and add a middle   Into Tag finding -          More discussion on extensibility versus versioning, some text towards end of http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html -          Expand and list trade-offs of: no namespace evolution (ie xslt), re-using namespace, and new namespace for new components in language when versioning.  Summarize choices author must make, ie “#1.  choose 1 of (single ns forever, evolvable ns, multiple ns) for versioning.  Choose 1 of (evolve schema in backwards compatible way, don’t evolve schema, don’t do backwards compatible evolution) when versioning. -          Move towards and add text on “substitutability must be in V1.0”, http://www.pacificspirit.com/blog/2004/05/26/substitution_rules_must_be_in_v10. -          Add material on various substitution rules, ranging from static (must ignore) to dynamic (xslt?), http://www.pacificspirit.com/blog/2004/06/14/whither_substitution_rules -          add protocol extensibility, http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_versioning -          Add material on issue about service compatibility (related to protocol extensibility), http://www.pacificspirit.com/blog/2004/06/29/interface_compatibility_v2   Create “Extensibility and versioning using various languages” document -          insert original xml schema material -          Optionally add Henry’s 2pass schema example (allows for default extensibility). -          add relax ng example -          add rdf/owl example, I have one in progress (@@) and there is some discussion on atom. -          Add delimiter technique, http://www.xml.com/pub/a/2004/07/21/design.html -          WSDL example for service extensibility (ie WSDL does not guarantee service compatibility), http://www.pacificspirit.com/blog/2004/06/29/using_wsdl_schema_for_compatible_evolution -          Issues of leaky abstraction of schema language choice(s) into types, particularly extensibility models.   Cheers, Dave