[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bdxr] Groups - Proposal for SMP xsd with Extension changes uploaded
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]