[glue-wg] [artf6175] some ideas for wildcards for associations in XML schema

[Paul Millar]

Hi all,

Looking at artf6175 "Wildcards in association", here are some possible 
solutions for how to represent a one-to-all mapping.

Option 1.  treat "*" is reserved localID that has special meaning.

<ExecutionEnvironment>
  <Assocations>
    <ApplicationEnvironmentLocalID>*</ApplicationEnvironmentLocalID>
  </Assocations>
</ExecutionEnvironment>

	I've included this one mainly for completeness.

	Pros: simple to implement

	Cons: hard to enforce, requires parsing of strings, goes against
		LocalID being any string.


Option 2.  Define a wildcard element with name "Wildcard" (or "AllIDs", or 
similar)

<ExecutionEnvironment>
  <Assocations>
    <ApplicationEnvironmentLocalID><AllIDs/></ApplicationEnvironmentLocalID>
  </Assocations>
</ExecutionEnvironment>

	Info providers should specify either only <AllIDs/> or some LocalID_t (i.e., 
a string), but never both:  "myID<allIDs/>" is not a valid value for 
ApplicationEnvironmentLocalID.

	Pros: Unlike 1, this protects the LocalID namespace (so "*" is a valid 
LocalID).
	Cons: we can't enforce this either-element-or-string with XSD validation (I 
think).


Option 3. Add an extra layer (LocalID or LocalIDRef, of type LocalID_t === 
string)

<ExecutionEnvironment>
  <Assocations>
    <ApplicationEnvironmentList>
      <LocalID>someID1</LocalID>
      <LocalID>someID2</LocalID>
      <LocalID>someID3</LocalID>
    </ApplicationEnvironmentList>
  </Assocations>
</ExecutionEnvironment>

<ExecutionEnvironment>
  <Assocations>
    <ApplicationEnvironmentList>
      <WildcardID/>
	<!-- or <AllIDs/>, or ... -->
    </ApplicationEnvironmentList>
  </Assocations>
</ExecutionEnvironment>

	Pros: allows enforcement of either 1 of Wildcard or 1..* of LocalID through 
XML Schema. 
		Like this, it may be useful elsewhere:
			define a generic type LocalIDList_t that is a complex type and has a choice 
of 1..* LocalIDs or precisely one WildcardID.
			ApplicationEnvironmentList is (or inherits from) LocalIDList_t.
			Other lists of localIDs could use (or inherit from) localIDList_t.

	Cons: has more elements

4. Add an <AllApplicationEnvironments/> element

<ExecutionEnvironment>
  <Assocations>
    <ApplicationEnvironmentLocalID>someID</ApplicationEnvironment>
  </Assocations>
</ExecutionEnvironment>

<ExecutionEnvironment>
  <Assocations>
    <AllApplicationEnvironments/>
  </Assocations>
</ExecutionEnvironment>

	Pros: reduced number of elements
	Cons: AllApplicationEnvironments is very specialised.


I think I'm in favour of option 3, but what do other people think?

Cheers,

Paul.