Re: [xml-dev] Which is better: overload the semantics of XML axes or create auxiliary elements and attach semantics to them?

I don't see any issue here.  The "semantics" are given entirely by the 
<approachTransition> element's existence, not by its placement or order 
as a child element:  by virtue of being an "approach transition" it is 
automatically earlier in time or landing sequence than a "final 
approach".  And the processing code will have to know this no matter 
what schema is used.

So go for simplicity.

TomP

On 6/29/2017 10:18 AM, Costello, Roger L. wrote:
> Hi Folks,
>
> Is it better to overload the semantics of XML axes or is it better to
> create auxiliary elements and attach semantics to them?
>
> Please, allow me to explain with an example.
>
> Upon entering an airport’s terminal airspace, an aircraft flies an
> *approach transition* followed by a *final approach*. There is one final
> approach. There may be multiple ways to get to the start of the final
> approach; that is, there may be multiple approach transitions.
>
> How to model multiple approach transitions funneling into one final
> approach?
>
> Approach #1: Overload the semantics of the following-sibling axis
>
> One approach is to add a semantic to the XML following-sibling axis:
> applications are to interpret a following sibling element to mean it
> occurs temporally and geospatially /after/ its preceding sibling
> element. Here is an XML instance that illustrates this approach:
>
> <approach>
>          <approachTransition>…</approachTransition>
>          <finalApproach>…</finalApproach>
> </approach>
>
> That has two disadvantages:
>
> 1. There are other elements in the XML document (not shown); the
> following siblings in those other elements are not to be interpreted
> with the semantic. So, the model is inconsistent: the XML following
> sibling axis means one thing in one part of the XML and another thing in
> another part of the XML.
>
> 2. Recall that “there may be multiple approach transitions.” How to
> model that? One might do this:
>
> <approach>
>          <approachTransition>…</approachTransition>
>          <approachTransition>…</approachTransition>
>          <approachTransition>…</approachTransition>
>          <finalApproach>…</finalApproach>
> </approach>
>
> But that is nonsensical under the semantic: an approach transition does
> not occur temporally and geospatially after another approach transition.
>
> Approach #2: Create auxiliary elements and attach semantics to them
>
> In this approach the following-sibling axis has no additional meaning; a
> following sibling element merely means that, in the XML document, it
> sequentially follows another element.
>
> Here is an instance that illustrates the second approach:
>
> <approach>
>      <alternativeApproachTransitions>
>          <approachTransition>...</approachTransition>
>          <approachTransition>...</approachTransition>
>          <approachTransition>...</approachTransition>
>      </alternativeApproachTransitions>
>      <funnelsInto>
>          <finalApproach>...</finalApproach>
>      </funnelsInto>
> </approach>
>
> The alternativeApproachTransition element is created and assigned this
> semantic: The child elements are to be interpreted as alternative
> approach transitions.
>
> The funnelsInto element is assigned this semantic: The child element is
> to be interpreted as a final approach that is to occur temporally and
> geospatially /after/ the preceding stuff.
>
> This second approach has a disadvantage: It is more verbose than the
> first approach.
>
> Question
>
> When modeling, in XML, the concept “this occurs after that” it is better to:
>
>  1. Overload the semantic of the following-sibling axis.
>  2. Create auxiliary elements and attach semantics to them
>  3. Something else (what?)
>  4. It doesn’t matter—approach#1 and approach#2 are equally good/bad
>
> /Roger
>