Re: [bdxr] Groups - Proposal for SMP xsd with Extension changes uploaded

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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