Found undefined alias


#1

The MuleSoft API Designer reports an undefined alias when an *alias reference precedes the &alias definition. Otherwise the file is syntactically correct.

Isn’t one of the design features of RAML that the order of the elements is unimportant? And doesn’t the (apparent) requirement that an alias definition precede all any reference to it break this goal? (Just sorting members in a properties map, can now break a correct definition.)

Or is this a misunderstanding on my part?


#2

Hi @mjk,

could you send an example RAML please. I’ll have a look :slight_smile:

Cheers,
Christian


#3
#%RAML 0.8
title: scratchpad
version: v2
/demo:
  /alpha:
    description: |
      This resource was added in v2.
      
      It was added alphabetically, just to be neat.  But
      the attempt to use the `standard-responses` alias
      is flagged as an error in "API Designer".  While it is
      true that &standard-responses anchor appears after this use,
      it is also true that there is exactly one definition
      and the definition is syntactically correct.
      
      YAML would complain here: http://yaml.org/spec/current.html#id2508656
      BUT RAML isn't YAML -- the API Designer complains if
      an anchor is defined twice, while this is explicitly
      allowed in YAML (see link).  You can see this second
      error message by changing the * in line 27 to an &
      
      So if RAML is going to limit the API designer
      to a single definition, and if RAML wants to 
      be order-insensitive, then I expect to get away with
      a forward reference :-)
    get:
      responses: *standard-responses
  /mike:
    description: |
      This resource was present in v1.
    get:
      responses: &standard-responses
        200:
        401:
        403:
  /zulu:
    description: |
      This resource was present in v1.
      
      It has no problem using the `standard-responses` alias.
    get:
      responses: *standard-responses
...