[DFDL-WG] proposal: assert message property as DFDL Expression or String - Fwd: proposal: add fn:error function ....
Mike Beckerle
mbeckerle.dfdl at gmail.com
Wed Jul 24 11:28:09 EDT 2013
As discussed on call 2013-07-24
Change to error behavior.
Any error that occurs during evaluation of the message property (whether
SDE or PE) will be issued as a separate recoverable error, and then an
implementation specific default message is used as the message for the
original assert, which is still processed as if there was no problem and in
a manner consistent with the original assert's failureType.
...mike
On Wed, Jul 24, 2013 at 7:34 AM, Steve Hanson <smh at uk.ibm.com> wrote:
> What happens if evaluating the message expression causes a schema
> definition error?
>
> Regards
>
> Steve Hanson
> Architect, IBM Data Format Description Language (DFDL)
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From: Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To: dfdl-wg at ogf.org,
> Date: 23/07/2013 16:44
> Subject: [DFDL-WG] proposal: assert message property as DFDL
> Expression or String - Fwd: proposal: add fn:error function ....
> Sent by: dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
> Proposed:
>
> Make the message property on dfdl:assert (and dfdl:discriminator) be
> either a string or a DFDL Expression that returns a string. (Note: this is
> not a DFDL String Literal, it is just a string.)
>
> Example:
> <dfdl:assert message="{ fn:concat('unknown whatever ', ../foobar) }">
> { if (...pred...) then ...expr1...
> else if (...pred2...) then ...expr2...
> else fn:false()
> }</dfdl:assert>
>
> If a processing error occurs while evaluating the test predicate, then
> that processing error occurs. The assert is not considered to have passed
> or failed because the assert predicate did not return ether true or false.
>
> If a processing error occurs while evaluating the message expression, then
> the assert causes an error of appropriate failureType: recoverableError or
> processingError, but an implementation-dependent message is provided.
>
>
> ---------- Forwarded message ----------
> From: *Steve Hanson* <*smh at uk.ibm.com* <smh at uk.ibm.com>>
> Date: Fri, Jul 12, 2013 at 4:25 AM
> Subject: Re: [DFDL-WG] proposal: add fn:error function and dfdl:hex
> function to DFDL
> To: Mike Beckerle <*mbeckerle.dfdl at gmail.com* <mbeckerle.dfdl at gmail.com>>
> Cc: *dfdl-wg at ogf.org* <dfdl-wg at ogf.org>, *dfdl-wg-bounces at ogf.org*<dfdl-wg-bounces at ogf.org>
>
>
> I agree that is simpler and making the message string an expression is an
> easy change to make.
>
> But in the your example if expr1 or expr2 evaluated to false, then in form
> #1 no message would be issued, but in form #2 it would be issued. Is that
> what you intended?
>
> Regards
>
> Steve Hanson
> Architect, IBM Data Format Description Language (DFDL)
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:*+44-1962-815848* <%2B44-1962-815848>
>
>
>
> From: Mike Beckerle <*mbeckerle.dfdl at gmail.com*<mbeckerle.dfdl at gmail.com>
> >
> To: *dfdl-wg at ogf.org* <dfdl-wg at ogf.org>,
> Date: 11/07/2013 18:47
> Subject: Re: [DFDL-WG] proposal: add fn:error function and
> dfdl:hex function to DFDL
> Sent by: *dfdl-wg-bounces at ogf.org* <dfdl-wg-bounces at ogf.org>
> ------------------------------
>
>
>
> Ignoring the dfdl:hexBinary thing.
>
> I want to suggest a different idea than fn:error function for DFDL:
>
> Suppose dfdl:assert (and dfdl:discriminator) message property could be an
> expression that evaluates to a string.
>
> Then instead of writing
>
> <dfdl:assert>{
> if (...pred...) then ...expr1...
> else if (...pred2...) then ...expr2...
> else fn:error(sym, fn:concat("unknown whatever ", ../foobar))
> }</dfdl:assert>
>
> You could write:
>
> <dfdl:assert message="{ fn:concat('unknown whatever ', ../foobar) }">
> { if (...pred...) then ...expr1...
> else if (...pred2...) then ...expr2...
> else fn:false()
> }</dfdl:assert>
>
> This is almost equivalent. But the message would respect the failureType
> of the assert.
>
> This has advantages.
>
> On Wed, Jul 10, 2013 at 3:14 PM, Garriss Jr., James P. <*
> jgarriss at mitre.org* <jgarriss at mitre.org>> wrote:
> > You need a different mechanism, which is a fatalError type for the
> dfdl:assert annotation.
>
> Sounds like we are in agreement. Thanks for clarifying.
>
>
>
> > But the CDS community uses validation to indicate an immediate need to
> stop. I.e., invalid == "dangerous".
>
> In some cases this is true, though in other cases it is not true. That’s
> why it seems to me that it would be good if DFDL can handle either
> mindset. For the work I’ve been doing with DFDL and email, the
> “invalid=dangerous” mindset was a starting assumption.
>
>
>
> *From:* Mike Beckerle [mailto:*mbeckerle.dfdl at gmail.com*<mbeckerle.dfdl at gmail.com>]
> *
> Sent:* Wednesday, July 10, 2013 1:57 PM*
> To:* Garriss Jr., James P.*
> Cc:* *dfdl-wg at ogf.org* <dfdl-wg at ogf.org>*
> Subject:* Re: [DFDL-WG] proposal: add fn:error function and dfdl:hex
> function to DFDL
>
>
>
> Actually, fn:error was added in order to allow a DFDL Expression to create
> a normal processing error.
>
> You need a different mechanism, which is a fatalError type for the
> dfdl:assert annotation.
>
> I have noticed that the use of 'validation' in DFDL is the opposite of the
> way other people use 'validation'. In the DFDL spec, validation generally
> just creates warnings and continues parsing. It can't even affect the parse
> unless you call checkConstrants(....) from an assert. But the CDS community
> uses validation to indicate an immediate need to stop. I.e., invalid ==
> "dangerous".
>
> ...mikeb
>
> On Wed, Jul 10, 2013 at 1:37 PM, Garriss Jr., James P. <*
> jgarriss at mitre.org* <jgarriss at mitre.org>> wrote:
>
> > fn:error, if called from inside an assert or discriminator, causes the
> assert or discriminator to fail (as with any processing error that occurs
> during evaluation of the assert or discriminator expression).
>
>
>
> Is this intended to address the issue I raised? If so, I think this is
> not sufficient. I need to have the option to cause a validation error, not
> a processing error. If not, please ignore this interruption. :-)
>
>
>
> *From:* *dfdl-wg-bounces at ogf.org* <dfdl-wg-bounces at ogf.org> [mailto:*
> dfdl-wg-bounces at ogf.org* <dfdl-wg-bounces at ogf.org>] *On Behalf Of *Mike
> Beckerle*
> Sent:* Tuesday, July 09, 2013 11:29 AM*
> To:* *dfdl-wg at ogf.org* <dfdl-wg at ogf.org>*
> Subject:* Re: [DFDL-WG] proposal: add fn:error function and dfdl:hex
> function to DFDL
>
>
>
> Proposal revised for dfdl:hex, and clarification added on fn:error when
> used inside assert.
>
> Revised language below:
>
> Proposed: add fn:error function and add dfdl:hexBinary function.
>
> DFDL only needs one of the several variations of fn:error.
>
> fn:error($error as xs:QName?, $description as xs:string) as none
>
> The behavior of fn:error in DFDL expressions is the same as described in
> XPath 2.0, an example is given below.
>
> dfdl:hexBinary($arg as xs:anyAtomicType?) as xs:hexBinary?
>
> This function provides an extension to the behavior of the xs:hexBinary
> constructor. The argument can be a string, in which case the behavior is as
> the xs:hexBinary constructor. The argument can also be a long,
> unsignedLong, or any subtype thereof, and in that case a string containing
> hexadecimal digits is produced. The hexadecimal digits produced that are
> letters are always uppercase. The number of hex digits in the resulting
> string is a function of the input type. If byte or unsigned byte, exactly 2
> hex digits are produced, for short and unsignedShort, 4 hex digits, and so
> on. The hex digits correspond to a big-endian representation of a
> twos-complement binary representation of the argument value. So:
>
> dfdl:short(xs:concat('x', dfdl:hexBinary(xs:short(208)))) eq xs:short(208)
>
> is true, and a corresponding tautology holds for all the other DFDL
> functions that construct integers from hexadecimal, if you replace the 208
> above with a value in range for the corresponding numeric type.
>
> If the argument is a numeric literal, then the smallest signed integer
> type (long, int, short, byte) is selected that can contain the value, and
> the number of hexadecimal digits produced corresponds to that type. So:
>
> dfdl:hexBinary(208) eq 'D0'
> dfdl:hexBinary(-2084) eq 'F7FF'
>
> Example of fn:error and dfdl:hexBinary:
>
> This expression allows a meaningful error message that includes the
> offending parts of data.
>
> fn:error(ex:magic_number, fn:concat("The magic number: 0x",
> dfdl:hexBinary(.), " was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1 (for
> littleEndian)."))
>
> The $error argument (of type QName) is used in an implementation-dependent
> manner to provide the context of the error. So for example, if namespace
> prefix 'ex' is bound to '*http://example.com* <http://example.com/>' then
> the above call might produce:
>
> "Error: {*http://example.com* <http://example.com/>}magic_number - The
> magic number: 0xFEFF0000 was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1
> (for littleEndian)."
>
> Only the part of the above string after the hyphen is standardized. The
> hyphen and part before the hyphen is implementation dependent.
>
> fn:error, if called from inside an assert or discriminator, causes the
> assert or discriminator to fail (as with any processing error that occurs
> during evaluation of the assert or discriminator expression). If the
> assert or discriminator has a message property, then it is implementation
> dependent how that message string is combined with the description string
> argument provided to the fn:error function.
>
> On Thu, Jun 20, 2013 at 1:09 PM, Mike Beckerle <*mbeckerle.dfdl at gmail.com*<mbeckerle.dfdl at gmail.com>>
> wrote:
>
>
> Proposed: add fn:error function and add dfdl:hex function.
>
> DFDL only needs one of the several variations of fn:error
>
> fn:error($error as xs:QName?, $description as xs:string) as none
>
> dfdl:hex($num as xs:integer) as string
>
>
> The dfdl:hex function inverts the behavior of the dfdl:byte, and related
> functions (currently also proposed) which take a string specification of a
> hex value. The argument to dfdl:hex can be a long, unsignedLong, or any
> subtype thereof. The number of hex digits in the resulting string is a
> function of the input type. If byte or unsigned byte, exactly 2 hex digits
> are produced, for short and unsignedShort, 4 hex digits, and so on. The
> resulting value contains a prefix 'x' character as its first character. So:
>
> dfdl:short(dfdl:hex(xs:short(208))) eq xs:short(208)
>
> is true, and a corresponding tautology holds for all the other DFDL
> functions that construct integers from hexadecimal, if you replace the 208
> above with a value in range for the corresponding numeric type.
>
> Example:
>
> This allows a meaningful error message that includes the offending parts
> of data.
>
> fn:error(ex:magic_number, fn:concat("The magic number: 0", dfdl:hex(.), "
> was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1 (for littleEndian)."))
>
> The $error argument (of type QName) is used in an implementation-dependent
> manner to provide the context of the error. So for example, if namespace
> prefix 'ex' is bound to '*http://example.com* <http://example.com/>' then
> the above call might produce:
>
> "Error: {*http://example.com* <http://example.com/>}magic_number - The
> magic number: 0xFEFF0000 was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1
> (for littleEndian)."
>
> Only the part of the above string after the hyphen is standardized. The
> hyphen and part before the hyphen is implementation dependent.
>
>
>
>
> --
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | *
> www.tresys.com* <http://www.tresys.com/>
>
>
>
>
> --
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | *
> www.tresys.com* <http://www.tresys.com/>
>
>
>
>
> --
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | *
> www.tresys.com* <http://www.tresys.com/>
> --
> dfdl-wg mailing list
> *dfdl-wg at ogf.org* <dfdl-wg at ogf.org>
> *https://www.ogf.org/mailman/listinfo/dfdl-wg*<https://www.ogf.org/mailman/listinfo/dfdl-wg>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
> --
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | *
> www.tresys.com* <http://www.tresys.com/>
> --
> dfdl-wg mailing list
> dfdl-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/dfdl-wg
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
--
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130724/01acc37f/attachment-0001.html>
More information about the dfdl-wg
mailing list