Hi Rumen,
I noticed strange behaviour with new 0.5.2/0.5.3 versions.
If I encode exi example (exipe-test.xsd etc) with exipe
I cannot anymore decode it with ExiFicient. With 0.5.1
there is no problem. There has been lot of changes since
0.5.1 but I think the problem relates to string handling
in ExipEncoder element. exipd decodes generated exi
correctly in all versions.
Thanks
Raino
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Rumen,
I noticed strange behaviour with new 0.5.2/0.5.3 versions.
If I encode exi example (exipe-test.xsd etc) with exipe
I cannot anymore decode it with ExiFicient. With 0.5.1
there is no problem. There has been lot of changes since
0.5.1 but I think the problem relates to string handling
in ExipEncoder element. exipd decodes generated exi
correctly in all versions.
Thanks
Raino
Hi Raino,
I filed a bug report based on your description:
https://sourceforge.net/p/exip/bugs/14/
This is just for bookkeeping - I've taken a break from work and the project for several months now so I won't be able to fix it any time soon.
Thanks for the feedback!
// Rumen
Change in src/grammar/grammars.c was not working correctly.
Going back to 0.5.1 code version helped.
=== 357,362 ====
--- 357,363 ----
if(WITH_STRICT(strm->header.opts.enumOpt))
{
// Strict mode
+ /*
if(strm->context.isNilType == FALSE && currentRuleIndx == 0)
{
if(IS_NILLABLE(strm->gStack->grammar->props))
===========
=== 369,374 ====
--- 370,381 ----
secondLevelExists = TRUE;
}
}
+ * /
+ if(currentRuleIndx == 0 && (IS_NILLABLE(strm->gStack->grammar->props) ||
+ HAS_NAMED_SUB_TYPE_OR_UNION(strm->gStack->grammar->props))
+ )
+ secondLevelExists = TRUE;
+
return getBitsNumber(prodCount - 1 + secondLevelExists);
}
else // Non-strict mode
BR Raino
Thank you Raino!
// Rumen