[jira] [Updated] (DAFFODIL-712) Error messages must mention the element reference and/or element, not just a type.

["Dave Thompson (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Thompson updated DAFFODIL-712:
-----------------------------------
    Labels: dev-verify  (was: reverify)

> Error messages must mention the element reference and/or element, not just a type.
> ----------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-712
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-712
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End, Diagnostics, Middle "End", Usability
>    Affects Versions: s9
>            Reporter: Mike Beckerle
>            Priority: Major
>              Labels: dev-verify
>
> 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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)