OASIS Business Document Exchange (BDXR) TC

Submitter's message Hi all,

based on the discusion yesterday I created a new version of the SMP xml schema definition that can handle multiple extensions and also allows to add extension attributes using the structure from BDE (but somewhat simpler using basic schema types). I think this schema definition is not a substantial change as XML document valid according to the current schema are still valid according to this schema. When adding an extra child element to the current Extension element this would not be the case and therefore I change the definition of the current Extension element.

Regards,
Sander -- Mr. Sander Fieten Document Name : Proposal for SMP xsd with Extension changes Description This xml schema definition contains a proposal for including multiple extensions and extension attributes.
For the extension attributes the structure is taken from the BDE schema, but using built-in XML schema types instead of custom defined types.

As XML documents that are valid under the current schema definitions are still valid under this schema the changes can be considered non substantive. Download Latest Revision Public Download Link Submitter : Mr. Sander Fieten Group : OASIS Business Document Exchange (BDXR) TC Folder : Working Drafts Date submitted : 2016-03-17 03:27:27

At 2016-03-17 03:27 -0700, Sander Fieten wrote: based on the discusion yesterday I created a new version of the SMP xml schema definition that can handle multiple extensions and also allows to add extension attributes using the structure from BDE (but somewhat simpler using basic schema types). I think this schema definition is not a substantial change as XML document valid according to the current schema are still valid according to this schema. When adding an extra child element to the current Extension element this would not be the case and therefore I change the definition of the current Extension element. Thank you for posting this, Sander. I have the following feedback regarding schema design, but I offer it without experience using SMP and so my focus is simply on principles I've used myself in design patterns in the past. I applied the principles to the extension point definition in BDE and in UBL. As was pointed out to me on the call yesterday, my "upper-layer" document perspective does not always apply to "lower-layer" deployments. For this reason you are more than welcome to dismiss my input. Moreover, I was not involved in earlier definitions of the schema and so my comments do not benefit from earlier discussions regarding approaches. Working with bdx-smp-20160317.xsd I find that I can include only a single extension at each extension point: <smp:Extension> <smp:ExtensionID>ExtensionID1</smp:ExtensionID> <smp:Extension...meta...></smp:Extension...meta...> <myExtension xmlns="myns"/> </smp:Extension> My recollection of the conference call discussion is that we need to accommodate multiple extensions at the extension point. BDE accommodates this with an extension container. For that I think we should include another layer in the structure: <smp:Extension> <smp:ExtensionInstance> <smp:ExtensionID>ExtensionID1</smp:ExtensionID> <smp:Extension...meta...></smp:Extension...meta...> <myExtension xmlns="myns"/> </smp:ExtensionInstance> <smp:ExtensionInstance> <smp:ExtensionID>ExtensionID2</smp:ExtensionID> <smp:Extension...meta...></smp:Extension...meta...> <myExtension2 xmlns="myns2"/> </smp:ExtensionInstance> </smp:Extension> Next, the BDE extension has a content container. Consider in the above that the XPath 2.0 address for the foreign elements (when they are not known) is: //smp:Extension/smp:ExtensionInstance/(* except smp:*) ... and in XPath 1.0: //smp:Extension/smp:ExtensionInstance/*[not(self::smp:*)] Introducing a content container in the hierarchy as follows: <smp:Extension> <smp:ExtensionInstance> <smp:ExtensionID>ExtensionID1</smp:ExtensionID> <smp:Extension...meta...></smp:Extension...meta...> <smp:ExtensionContent> <myExtension xmlns="myns"/> </smp:ExtensionContent> </smp:ExtensionInstance> <smp:ExtensionInstance> <smp:ExtensionID>ExtensionID2</smp:ExtensionID> <smp:Extension...meta...></smp:Extension...meta...> <smp:ExtensionContent> <myExtension2 xmlns="myns2"/> </smp:ExtensionContent> </smp:ExtensionInstance> </smp:Extension> ... would make the XPath 1.0 or 2.0 address of the foreign elements (when they are not known) the following: //smp:Extension/smp:ExtensionInstance/smp:ExtensionContent/* But you may not wish to have another level in the hierarchy ... I don't find that a burden in the work I've done. Finally, I note that the schema expression is a monolithic XSD file. I suggest this expression should be delivered as two XSD files, where in the primary file we have: <xsd:include schemaLocation="bdx-smp-extensions.xsd"/> ... <xsd:element name="ExtensionContent" type="ExtensionContentType"/> ... and in a second "bdx-smp-extensions.xsd" XSD file we have only the one type declaration and no element declarations: <xs:complexType name="ExtensionContentType"> <xs:sequence> <xs:any namespace="##other" processContents="lax"/> </xs:sequence> </xs:complexType> In BDE and UBL this is done so that when a deployment wants to add the definition of an extension, only the one content type XSD expression file is touched. All of the other XSD expression files can remain read-only and untouched. This prevents inadvertently disturbing the XSD expression and gives one a level of assurance that the including XSD file has not been corrupted from the one delivered by OASIS. All an implementer has to do with the included "bdx-smp-extensions.xsd" file is add some <xsd:import> directives in order to validate their expected content under the <smp:ExtensionContent> element. Although I wouldn't recommend it for SMP, this approach does allow an implementation to *enforce* the existence of the extension by changing the declaration. Or constraining the apex of the extension to be one of a subset of elements found in the extension schema. There are still shortcomings, however, because SMP has multiple extension points in the instance. The extension content customization makes more sense in BDE where there is only a single extension point in the entire document under which all extensions go. Still, I think we should offer the opportunity to customize the constraints on SMP extension content in a deployment. I was unaware until today that SMP offers contextual extension points. I was also unaware that SMP extensions are found at the end of the parent element to which the extensions apply (if I've understood the schema correctly). In BDE and UBL I've created one extension point only per instance and it is always the first child of the document element. Such an approach forces a streaming application to encounter all of the extensions before encountering any standard construct. This prepares the application to interpret the standard construct in the context of any extensions because the extensions have already been found and interpreted. By placing extensions after elements, a streaming application doesn't know how to interpret a standard construct until it gets to the end of the parent construct to discover whether or not there are any extension semantics to be considered. This triggers awkward buffering and uncertainty when a streaming application serially processes the content. But for backward compatibility, nothing in this regard can change in SMP. I recognize that historically XML extension points were at the end of parent elements because of influences of database design where extension bits follow standard bits. However, it has been my experience that application design is simplified when extensions are encountered first and so I proposed that approach for UBL and it was accepted by that team. I followed through doing the same thing in BDE. I hope this is considered useful input. . . . . . . . Ken -- Check our site for free XML, XSLT, XSL-FO and UBL developer resources Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Thank you Sander and Ken! I believe that we have 5 extension points in SMP (inside the ServiceInformationType, ProcessType, EndpointType, ServiceGroupType, and RedirectType containers). In the bdx-smp-20160317.xsd I find that only the ServiceInformationType container supports unbounded extensions, is that intended? Other than that I have no comments to the schema. Following Ken's rationalization at last week's meeting we should probably review the extension strategy for an SMP version 2.0, but with the current version I think backwards compatibility has higher priority. Best regards, Kenneth On 3/17/16, 10:23 AM, "bdxr@lists.oasis-open.org on behalf of G. Ken Holman" <bdxr@lists.oasis-open.org on behalf of gkholman@CraneSoftwrights.com> wrote: >At 2016-03-17 03:27 -0700, Sander Fieten wrote: >>based on the discusion yesterday I created a new version of the SMP >>xml schema definition that can handle multiple extensions and also >>allows to add extension attributes using the structure from BDE (but >>somewhat simpler using basic schema types). I think this schema >>definition is not a substantial change as XML document valid >>according to the current schema are still valid according to this >>schema. When adding an extra child element to the current Extension >>element this would not be the case and therefore I change the >>definition of the current Extension element. > >Thank you for posting this, Sander. > >I have the following feedback regarding schema design, but I offer it >without experience using SMP and so my focus is simply on principles >I've used myself in design patterns in the past. I applied the >principles to the extension point definition in BDE and in UBL. As >was pointed out to me on the call yesterday, my "upper-layer" >document perspective does not always apply to "lower-layer" >deployments. For this reason you are more than welcome to dismiss my input. > >Moreover, I was not involved in earlier definitions of the schema and >so my comments do not benefit from earlier discussions regarding approaches. > >Working with bdx-smp-20160317.xsd I find that I can include only a >single extension at each extension point: > > <smp:Extension> > <smp:ExtensionID>ExtensionID1</smp:ExtensionID> > <smp:Extension...meta...></smp:Extension...meta...> > <myExtension xmlns="myns"/> > </smp:Extension> > >My recollection of the conference call discussion is that we need to >accommodate multiple extensions at the extension point. BDE >accommodates this with an extension container. For that I think we >should include another layer in the structure: > > <smp:Extension> > <smp:ExtensionInstance> > <smp:ExtensionID>ExtensionID1</smp:ExtensionID> > <smp:Extension...meta...></smp:Extension...meta...> > <myExtension xmlns="myns"/> > </smp:ExtensionInstance> > <smp:ExtensionInstance> > <smp:ExtensionID>ExtensionID2</smp:ExtensionID> > <smp:Extension...meta...></smp:Extension...meta...> > <myExtension2 xmlns="myns2"/> > </smp:ExtensionInstance> > </smp:Extension> > >Next, the BDE extension has a content container. Consider in the >above that the XPath 2.0 address for the foreign elements (when they >are not known) is: > > //smp:Extension/smp:ExtensionInstance/(* except smp:*) > >... and in XPath 1.0: > > //smp:Extension/smp:ExtensionInstance/*[not(self::smp:*)] > >Introducing a content container in the hierarchy as follows: > > <smp:Extension> > <smp:ExtensionInstance> > <smp:ExtensionID>ExtensionID1</smp:ExtensionID> > <smp:Extension...meta...></smp:Extension...meta...> > <smp:ExtensionContent> > <myExtension xmlns="myns"/> > </smp:ExtensionContent> > </smp:ExtensionInstance> > <smp:ExtensionInstance> > <smp:ExtensionID>ExtensionID2</smp:ExtensionID> > <smp:Extension...meta...></smp:Extension...meta...> > <smp:ExtensionContent> > <myExtension2 xmlns="myns2"/> > </smp:ExtensionContent> > </smp:ExtensionInstance> > </smp:Extension> > >... would make the XPath 1.0 or 2.0 address of the foreign elements >(when they are not known) the following: > > //smp:Extension/smp:ExtensionInstance/smp:ExtensionContent/* > >But you may not wish to have another level in the hierarchy ... I >don't find that a burden in the work I've done. > >Finally, I note that the schema expression is a monolithic XSD >file. I suggest this expression should be delivered as two XSD >files, where in the primary file we have: > > <xsd:include schemaLocation="bdx-smp-extensions.xsd"/> > ... > <xsd:element name="ExtensionContent" type="ExtensionContentType"/> > >... and in a second "bdx-smp-extensions.xsd" XSD file we have only >the one type declaration and no element declarations: > > <xs:complexType name="ExtensionContentType"> > <xs:sequence> > <xs:any namespace="##other" processContents="lax"/> > </xs:sequence> > </xs:complexType> > >In BDE and UBL this is done so that when a deployment wants to add >the definition of an extension, only the one content type XSD >expression file is touched. All of the other XSD expression files >can remain read-only and untouched. This prevents inadvertently >disturbing the XSD expression and gives one a level of assurance that >the including XSD file has not been corrupted from the one delivered by OASIS. > >All an implementer has to do with the included >"bdx-smp-extensions.xsd" file is add some <xsd:import> directives in >order to validate their expected content under the ><smp:ExtensionContent> element. > >Although I wouldn't recommend it for SMP, this approach does allow an >implementation to *enforce* the existence of the extension by >changing the declaration. Or constraining the apex of the extension >to be one of a subset of elements found in the extension >schema. There are still shortcomings, however, because SMP has >multiple extension points in the instance. > >The extension content customization makes more sense in BDE where >there is only a single extension point in the entire document under >which all extensions go. Still, I think we should offer the >opportunity to customize the constraints on SMP extension content in >a deployment. > >I was unaware until today that SMP offers contextual extension >points. I was also unaware that SMP extensions are found at the end >of the parent element to which the extensions apply (if I've >understood the schema correctly). > >In BDE and UBL I've created one extension point only per instance and >it is always the first child of the document element. Such an >approach forces a streaming application to encounter all of the >extensions before encountering any standard construct. This prepares >the application to interpret the standard construct in the context of >any extensions because the extensions have already been found and >interpreted. By placing extensions after elements, a streaming >application doesn't know how to interpret a standard construct until >it gets to the end of the parent construct to discover whether or not >there are any extension semantics to be considered. This triggers >awkward buffering and uncertainty when a streaming application >serially processes the content. > >But for backward compatibility, nothing in this regard can change in SMP. > >I recognize that historically XML extension points were at the end of >parent elements because of influences of database design where >extension bits follow standard bits. However, it has been my >experience that application design is simplified when extensions are >encountered first and so I proposed that approach for UBL and it was >accepted by that team. I followed through doing the same thing in BDE. > >I hope this is considered useful input. > >. . . . . . . Ken > > >-- >Check our site for free XML, XSLT, XSL-FO and UBL developer resources >Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK >Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ >G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com >Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts >Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal > > >--- >This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >