[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Which is better: overload the semantics of XML axes orcrea

  • From: David Carlisle <d.p.carlisle@gmail.com>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Thu, 29 Jun 2017 15:40:12 +0100

Re:  Which is better: overload the semantics of XML axes orcrea
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.