Make CDSignatures or Signature use cdbase

[kohlhase]

see https://github.com/OpenMath/OM3/issues/128 and also take https://github.com/OpenMath/OM3/issues/133 into account.

[kohlhase]

I think that cdbase was intended there, and we can therefore clarify the standard to make it so. Assigning to David and James to develop a pull request to clarify the situation.

[davidcarlisle]

I do not really think that anything is really broken here, the underlying assumption throughout openmath has always been that you can reference things by cdname. One might argue that that doesn't scale but referencing by simple name works for example for latex (\usepackage{color} means what it means) and the openmath community would have to scale a lot before it was comparable to the size of the latex community.

However putting explicit urls can help people find things and it would make sense to add cdbase to CDsignatures (I would just allow it at the top level)

Note referencing by url isn't always a win, as we see currently, cds can move hosts and change URL but arith1 is arith1 so the original idea of just referencing by name still has practical benefits in many but not all scenarios.

[kohlhase]

I am not sure that I agree with the notion that LaTeX solution scales. We do see a lot of unintended macro redefinitions (not everybody uses \newcommand.).

However putting explicit urls can help people find things and it would make sense to add cdbase to CDsignatures (I would just allow it at the top level)

this seems to me a reasonable middle path and I support this.

BUT I am not sure which of the two problems

• what is the cdbase of the symbols used in the CDsignatures (i.e. OpenMath/OM3/128)
• what is the cdbase of the CD this is for (i.e. OpenMath/OM3#133). you want to solve with this. Can you clarify?

[davidcarlisle]

I am not sure that I agree with the notion that LaTeX solution scales. We do see a lot of unintended macro redefinitions (not everybody uses \newcommand.).

I was comparing cdnames to package names, ctan acts as a central registry just by existing and so users refer to packages just by name \usepackage{xcolor} and xcolor is in practice whatever you last got from

https://ctan.org/tex-archive/macros/latex/xcolor

There is no way to reference a package other than by a local name, and if you want that name to be globally usable submit it to ctan (who will accept it if it meets minimal conditions like having a unique name and a licence that allows them to post it) in practice this is used for thousands of packages and millions (possibly) of users every day.

The only issue that I think needs to be addressed is

what is the cdbase of the CD this is for (i.e. OpenMath/OM3#133).

This one isn't an issue at all

what is the cdbase of the symbols used in the CDsignatures (i.e. OpenMath/OM3/128)

You can already put cdbase= on the OMOBJ or at a finer grain on elements within the OMOBJ.

[kohlhase]

I was comparing cdnames to package names, ctan acts as a central registry just by existing

ah, you are right of course, now I agree :-)

And you have convinced me on the other points too. So we should indeed just add a cdbase attribute to the CDSginatures element.

[davidcarlisle]

So we should indeed just add a cdbase attribute to the CDSginatures element.

I had a thought while driving in that since the top level URL is just a way of referring to the single CD for which this is the signature then it might be more natural to add a cdurl=... rather than cdbase =. so that as well as the name you could optionally give the canonical url of the CD for which this is the signature.

[kohlhase]

I can see that. That may even be more explicit than the cdbase/cdname pair.

[kohlhase]

I do not really care either way.

[kohlhase]

Oh, now that we have #57, we should probably also add a cdgroup attribute to the CDSignatures element (and to the CD element while we are at it).

Then we do not need the cdurl attribute that you suggest, because the cd attribute is enough as (presumably) it is given a URL by the cdgroup catalog.

What do you think? This seems more uniform to me.

[davidcarlisle]

I am not sure we should add cdgroup to CD. CDs can be (typically are) in multiple groups.

I'm not sure that we shouldn't add it either, but it is making changes way beyond the scope of the original suggestion and I'd suggest it isn't needed for 2.0r2.

If it is added it needs documenting as a cdgroup for interpreting symbols within the CD (rather than being the cdgroup in which this CD lives) and the exact details would need to be sorted out and It's not a clear win.

[kohlhase]

This is taken care of in PR #63

[kohlhase]

I am not sure we should add cdgroup to CD. CDs can be (typically are) in multiple groups.

hmmmm, you are right. In the PR I specified that the cdgroup for inheritance for OMOBJ and that does not solve the problem here. So I guess we should go with your solution of a cdurl attribute.

I will add that to the PR.

[kohlhase]

I must say that I really appreciate the travis-based error-checking facilities (as you can imagine).

[kohlhase]

OK, I have added the cdurl attribute to the PR and - while I was at it - extended the description of the XML encoding of CD Signatures (that was missing).

[kohlhase]

OK, closing again, please discuss on #63