Re: [xml-dev] Which is better: overload the semantics of XML axes orcrea

[David Carlisle <d.p.carlisle@gmail.com>]

On 29 June 2017 at 15:18, Costello, Roger L. <costello@mitre.org> 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:
>
> Overload the semantic of the following-sibling axis.
> Create auxiliary elements and attach semantics to them
> Something else (what?)
> It doesn’t matter—approach#1 and approach#2 are equally good/bad
>
>
>
> /Roger

The two approaches you outline are the same, and neither requires any
interpretation of the sibling axis (which anyway is xpath rather than
xml concept)


when defining what your elements mean you have defined that there can
be at most one approachTransition that applies, from a choice of many
and exactly one finalApproach

Given that definition, the order of elements doesn't matter and you could have

 <approach>
         <approachTransition>…</approachTransition>
         <approachTransition>…</approachTransition>
         <finalApproach>…</finalApproach>
         <approachTransition>…</approachTransition>
 </approach>

with no loss of ambiguity.
In situations where element order doesn't matter it's sometimes useful
to force a canonical form (eg  <finalApproach> last) but only to help
simplify some comparison operations  it doesn't affect any meaning or
most processing.

David