[DFDL-WG] proposal: add fn:error function and dfdl:hex function to DFDL

Fri Jul 12 08:25:39 EDT 2013

On Fri, Jul 12, 2013 at 4:25 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> 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?
>
>
I think this is an artifact of my contrived example. More realistically
each of expr1 and expr2 would be fn:true(), because really, the decision is
in the corresponding pred1 and pred2, or they would be another tree of
complex conditional branch each leaf ending in fn:error or fn:true().

So in the version that calls fn:error false/fail is always a call to
fn:error instead.

In the version where message is an expression, false/fail is fn:false(),
then the message prints.

A  large complicated decision tree with many different fn:error calls at
the leaves (in the fn:error formulation) will convert into several distinct
assert statements in the other formulation. One assert per distinct
message.

>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        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
> ------------------------------
>
>
>
> 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
>  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/20130712/cf8c46d3/attachment-0001.html>