[
https://issues.apache.org/jira/browse/DAFFODIL-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olabusayo Kilo updated DAFFODIL-712:
------------------------------------
Fix Version/s: (was: 4.0.0)
> 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: Minor
> 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. [[email protected]]
> Sent: Tuesday, May 14, 2013 2:25 PM
> To: Mike Beckerle; Stephen Lawrence
> Cc: [email protected]
> 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.20.10#820010)
