Hexadecimal in OMI

[lars-hellstrom]

I was writing up a summary of the format of digits in integer objects —

The XML encoding of OMIs and OMFs can be in hexadecimal as well as decimal, if one wishes to avoid a radix conversion. The binary encoding is base-2 (well, perhaps rather base-256) only. In the case of integers, hexadecimal is signalled with an x before the first digit (but after the minus sign, if there is one).

— because that is what Section 3.1.2 of the standard says. But then I though I'd better check if the hexdigits are upper case, lower case, or both. To my surprise, the normative RNG schema says it's neither, because Appendix B states:

  <!-- integer -->
  <define name="OMI">
    <element name="OMI">
      <ref name="common.attributes"/>
      <data type="string">
        <param name="pattern">\s*(-\s?)?[0-9]+(\s[0-9]+)*\s*</param>
      </data>
    </element>
  </define>

This covers only the case of decimal digits, so the standard contradicts itself!

From a technical point of view, I think it would be a good idea to support hexadecimal here, and would be inclined to treat this as an error in the writeup, but since it would mean changing the schema I suppose it could be sensitive (someone might have implemented a tool correctly against the schema, rather than against the informal text description). As for the other encodings:

• CMML supports hexadecimal (with both upper and lower case), but only in pragmatic CMML.
• PopCorn supports hexadecimal (with both upper and lower case, although the prefix seems to be lower case x only).

What does OpenDreamKit do?

Is this an issue that could be addressed by / call for a minor increment in the OMOBJ version? (That is, if we don't decide to pretend that the standard always was with hexadecimal, and instead decide that "yes, technically this is a change".) It would not affect what could be an abstract OM object, only how some objects could be encoded; I'm not sure if the version is for the encoding or for the abstract model.

[JamesHDavenport]

That certainly looks like an inconsistency, but David's our RNG guru. James Davenport Fulbright CyberSecurity Scholar (at New York University) Hebron & Medlock Professor of Information Technology, University of Bath National Teaching Fellow 2014 OpenMath Content Dictionary Editor Director of Studies EPSRC Doctoral Taught Course Centre for HPC Chair, IMU Committee on Electronic Information and Communication Vice-President and Academy Trustee, British Computer Society

…

________________________________ From: lars-hellstrom <[email protected]> Sent: Monday, August 28, 2017 11:08 AM To: OpenMath/OMSTD Cc: Subscribed Subject: [OpenMath/OMSTD] Hexadecimal in OMI (#5) I was writing up a summary of the format of digits in integer objects - The XML encoding of OMIs and OMFs can be in hexadecimal as well as decimal, if one wishes to avoid a radix conversion. The binary encoding is base-2 (well, perhaps rather base-256) only. In the case of integers, hexadecimal is signalled with an x before the first digit (but after the minus sign, if there is one). - because that is what Section 3.1.2 of the standard<https://openmath.github.io/standard/om20-2017-07-22/omstd20.html#sec_xml-desc> says. But then I though I'd better check if the hexdigits are upper case, lower case, or both. To my surprise, the normative RNG schema says it's neither, because Appendix B states: <!-- integer --> <define name="OMI"> <element name="OMI"> <ref name="common.attributes"/> <data type="string"> <param name="pattern">\s*(-\s?)?[0-9]+(\s[0-9]+)*\s*</param> </data> </element> </define> This covers only the case of decimal digits, so the standard contradicts itself! From a technical point of view, I think it would be a good idea to support hexadecimal here, and would be inclined to treat this as an error in the writeup, but since it would mean changing the schema I suppose it could be sensitive (someone might have implemented a tool correctly against the schema, rather than against the informal text description). As for the other encodings: * CMML supports hexadecimal (with both upper and lower case), but only in pragmatic CMML. * PopCorn supports hexadecimal (with both upper and lower case, although the prefix seems to be lower case x only). What does OpenDreamKit do? Is this an issue that could be addressed by / call for a minor increment in the OMOBJ version? (That is, if we don't decide to pretend that the standard always was with hexadecimal, and instead decide that "yes, technically this is a change".) It would not affect what could be an abstract OM object, only how some objects could be encoded; I'm not sure if the version is for the encoding or for the abstract model. - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#5>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGvamaZr4JRxOJAdiPQfuKlYJAc1lHABks5scpGugaJpZM4PEVBM>.

[kohlhase]

assigning to David and Lars, I can help if necessary.

[davidcarlisle]

the doc was fairly clear that the content of OMI should ignore spaces and then be an optional leading - followed by decimal or x and uppercase hex.

So I have updated the schema to match.

The schema doesn't really have any formal versioning but I added a comment at the top

# RELAX NG Schema for OpenMath 2
# Revision 2: Corrected regex for OMI to match the documented standard and allow hex

This is checked into OMSTD and CDs repos (it would be good to avoid that duplication if possible) and will get checked in to OpenMath.github.io in editors-draft area when that's rebuilt.

I seem to have messed up the checkin reference to this issue as I don't see it here, the check is

OpenMath/CDs@b62ed53

[lars-hellstrom]

I like that you added the Kleene stars on the whitespace – this was also bugging me in the RNG.

But you seem to have done this against the wrong repo (somehow). The #5 reference in that commit should go to #5, but it goes to OpenMath/CDs#5.

[davidcarlisle]

But you seem to have done this against the wrong repo (somehow). The #5

reference in that commit should go to OpenMath/OMSTD#5 <#5>, but it goes to OpenMath/CDs#5 <OpenMath/CDs#5>. yes seems wrong that I need to check in two "master" copies and I checked them in the wrong order so put the # link in the wrong commit however I added a link to the commit diff by hand to the real issue 5 so no harm done:-)

…

On 3 October 2017 at 13:42, lars-hellstrom ***@***.***> wrote: I like that you added the Kleene stars on the whitespace – this was also bugging me in the RNG. But you seem to have done this against the wrong repo (somehow). The #5 reference in that commit should go to OpenMath/OMSTD#5 <#5>, but it goes to OpenMath/CDs#5 <OpenMath/CDs#5>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNcAumb2BUhY2c-8pZt1bhesbhPoLpjks5soivKgaJpZM4PEVBM> .

[kohlhase]

is this fixed then?

[kohlhase]

If so, please close.

[davidcarlisle]

I left it open as it needs an entry in the change log and I don't want to add that until after the uri branch is pulled otherwise I'll get merge conflicts as that adds an OM2r2 change log section as well, but yes it's fixed once that's done

…

On 5 October 2017 at 10:09, Michael Kohlhase ***@***.***> wrote: If so, please close. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNcAvpQ5iiQnSDBdBnjhW4uTQe--_Alks5spJzegaJpZM4PEVBM> .