[artf6175] some ideas for wildcards for associations in XML schema

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.
participants (1)
-
Paul Millar