Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DAFFODIL-712

Error messages must mention the element reference and/or element, not just a type.

    XMLWordPrintableJSON

Details

    Description

      It is a bug if an error message only mentions the location of a type definition, and not the element, because obviously a named type can be shared and have instances all over the place, only one of which is violating its constraints.

      James Garriss was moving asserts around from types to elements so as to get a better diagnostic message. The message shouldn't actually change (much) if an assert moves from a shared type definition to an element.

      This may be a general principle our error messages are not dealing with currently. If you have a global element declaration for example, then unless it is the root element, any errors should definitely give you file and line number for the element reference. Similarly types have to give you the location of the specific element of that type. (which then might mean the specific location of an element reference if the element was a global element declaration).

      So, you will want file and line number of exactly what assert failed, and ideally, of exactly the constraint itself (e.g., the pattern facet definition), you also need the file and line for the point of usage of the type/element.

      ________________________________________
      From: Garriss Jr., James P. [jgarriss@mitre.org]
      Sent: Tuesday, May 14, 2013 2:25 PM
      To: Mike Beckerle; Stephen Lawrence
      Cc: jcranford@mitre.org
      Subject: RE: [daffodil] explosion on a choice

      > You want checkConstraints() to be called in an assert, on every element of simple type that has any constraints.

      Concur.

      > The convenient way to do this is by defining your own library of simple types

      Already exists.

      > put the asserts there, then express the schema as elements of those types exclusively.

      I started it that way, but then moved the checkConstraints up to higher level elements. My reason is because the error messages made more sense at the higher level.

      For example.

      Plain email
      Sequence
      Local part (type = atomic)
      Domain (type = atomic or domain)

      Atomic (restricted string)
      Domain (restricted string)

      If I put the checkConstraint on Local part (instead of Atomic), the error message can say something specific about local parts. Easier to understand/debug.

      Attachments

        Activity

          People

            Unassigned Unassigned
            mbeckerle Mike Beckerle
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: