and
On parsing the dfdl:escapeBlockStart string must be the first characters in the (trimmed) data in order to activate the escape scheme. The dfdl:escapeBlockStart string is removed from the beginning of the data. Until a matching dfdl:escapeBlockEnd string (that is, one not preceded by the dfdl:escapeEscapeCharacter) is found in the data, any in-scope terminating delimiter encountered in the data is not interpreted as such, and any dfdl:escapeEscapeCharacters are removed when they precede an dfdl:escapeBlockEnd string.
Now consider a a model where:
escapeBlockStart="start"
escapeBlockEnd="end"
escapeEscapeCharacter="#"
Then take a logical value of:
A hash is a #
When we serialize the value, we wrap the value with the escapeBlockStart
and escapeBlockEnd, and we preceed any instance of the escapeBlockEnd within
the data with an escapeEscapeCharacter. This then gives us the
physical value "startA hash is a #end". If we were to parse
that data, we see the "#end" as an escaped escapeBlockEnd and
report that there is no escapeBlockEnd.
The gap in the behavioural definition seems to be that the specification
makes no claim to do anything to escape an instance of an escapeEscapeCharacter
when serializing; There is nothing to catch the case of an escapeEscapeCharacter
that isn't escaping an escapeBlockEnd but ends up doing it by circumstance.
Andy
Andy Edwards - IBM Integration Bus - DFDL | |||||||||||
| The
Feynman problem solving Algorithm 1) Write down the problem 2) Think real hard 3) Write down the answer -- Murray Gell-mann in the NY Times |
--
dfdl-wg mailing list
dfdl-wg@ogf.org
https://www.ogf.org/mailman/listinfo/dfdl-wg
--
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