RE: [regrep] Proposed resolution for Element substitution issue

["Richard Martell" <rmartell@galdosinc.com>]

Hi all,


The proposed resolution for REGREPTC-120 is fine.

By way of summary, here's the argument in favour of not prohibiting element 
substitutions (REGREPTC-120):

* better compatibility with v3, which declared element substitution groups 
  other specs rely on (e.g. OGC:CSW-ebRIM); a major revision doesn't _require_ 
  backwards-incompatible changes!

* makes extensibility points more transparent to profilers by explicitly 
  indicating where extension elements may appear;

* the use of element substitution groups is a very widespread XML Schema 
  practice (e.g. ISO:19136,19139,191xx; OASIS:XACML; NIEM; OGC:KML; 
  FAA/EUROCONTROL:AIXM).


The dichotomy between element- and type-substitution is wired deeply 
into XML Schema, and after 10 years no consensus has arisen; indeed, it
lives on in current v1.1 drafts. So personally I'm inclined to remain 
ecumenical on this point, but will go with the majority opinion.

P.S. 
In my experience tool support tends to be haphazard; some readily support 
both substitution mechanisms, others offer only partial support for XML 
Schema.


--
Richard 


> -----Original Message-----
> From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com] 
> Sent: Wednesday, 17 March, 2010 12:40
> To: ebXML Regrep
> Subject: [regrep] Proposed resolution for Element substitution issue
> 
> Dear colleagues,
> 
> Oliver, Richard and I have been working on the following 
> important issues:
> 
> 
> *	No substitutionGroup assignments in rim.xsd 
> <http://wxforge.wx.ll.mit.edu:8080/jira/browse/REGREPTC-121> 
> *	No global RegistryObject element declaration in rim.xsd 
> <http://wxforge.wx.ll.mit.edu:8080/jira/browse/REGREPTC-120> 
> 
> 
> In tomorrow's TC meeting Oliver and I would like to propose 
> the following resolution of these issues:
> 
> 1. Remove all global elements corresponding to all 
> RegistryObjectType sub-types types (e.g. 
> rim:ClassificationScheme, rim:ClassificationNode, ...)
> 
> 2. Add global element: 
> 
> <element name="RegistryObject" type="tns:RegistryObjectType"/>
> 
> 3. Change the current definition of rim:RegistryObjectListType to:
> 
>  <complexType name="RegistryObjectListType">
>     <sequence>
>       <element ref="tns:RegistryObject" minOccurs="0" 
> maxOccurs="unbounded" />
>     </sequence>
>   </complexType>
> 
> As a side effect of this change rest of schema to reuse 
> rim:RegistryObjectList element instead of using similar local 
> declarations.
> 
> 4. Do not add element substitution
> 
> Rationale (Oliver's and mine) for proposed solution are:
> 
> (1) Avoids the problem of multiple representations (one with 
> xsi:type and one without) for RegistryObjectType sub-types
> 
> (2) Enables an ebRIM format document to have any 
> RegistryObjectType instance as a root element using new 
> rim:RegistryObject element. This element will have only one 
> representation that uses xsi:type
> 
> (3) Reuses the global definition added by (2)
> 
> (4) Provides better support for XML databinding tools which 
> have more issues with element substitution and because 
> database storage requires storing element QName in addition 
> to other information for no functional reason.
> 
> I believe the schema is much better with above changes thanks 
> to Richard's valuable input. 
> 
> Richard, I believe you support (1), (2) and (3). I realize 
> that (4) is not what you prefer. I hope you will consider 
> this proposed resolution as a "half-full glass" and a result 
> of serious consideration after spending considerable effort 
> looking at implications of adding element substitution. I 
> hope we will get beyond the element substitution issue and 
> collaborate closely on the remaining work for RegRep 4 specifications.
> 
> Attached to this email are:
> 
> 
> *	regrep-spec-cd5-SNAPSHOT.zip - Contains spec artifcats 
> with proposed changes including resolution for an unrelated issue:
> 	Upgrade to XLink 1.1 
> <http://wxforge.wx.ll.mit.edu:8080/jira/browse/REGREPTC-152>  
> (Richard please review the change for this)
> *	diff-remove-global-elements.txt - Contains the changes 
> to spec artifacts since last version in patch diff format
> 	
> 
> Lastly, I would like to suggest that each of us review the 
> open issues to see which of them may have a potential for 
> high impact in schema and WSDL. We should get these issues 
> resolved at the highest priority so the schema and wsdl are 
> stable with CD5.
> 
> Kathryn, for tomorrws meeting agenda may I propose the following:
> 
> 
> *	Review of proposed resolution and (hopefully) approval of it
> *	Discussion on high priority issues identified as 
> potentially impacting schema and wsdl files
> 	
> *	Discussion on a rapid release of CD5 with changes 
> resulting from proposed resolution and any other bugs 
> identified in time
> 
> 
> Thank you.
> 
> -- 
> Regards,
> Farrukh
> 
> Web: http://www.wellfleetsoftware.com
> 
>