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@gmail.com]
Sent: Wednesday, July 10, 2013 1:57 PM
To: Garriss Jr., James P.
Cc: dfdl-wg@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@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@ogf.org
[mailto:dfdl-wg-bounces@ogf.org]
On Behalf Of Mike Beckerle
Sent: Tuesday, July 09, 2013 11:29 AM
To: dfdl-wg@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'
then the above call might produce:
"Error: {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@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'
then the above call might produce:
"Error: {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
--
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
--
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
--
dfdl-wg mailing list
dfdl-wg@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