Allow OMOBJ in OMCD texts

[jbs1]

migrated from Trac, where originally posted by kohlhase on 23-Sep-2013 8:29am

We should allow (and use in the standard CDs) the use of OMOBJ for formulae in the OMCDs. With the Notation Definitions in SEP #144, this would allow for better presentation and more interaction.

[jbs1]

migrated from Trac, where originally posted by lars_h on 7-Oct-2013 10:14am

Replying to [ticket:145 kohlhase]:

We should allow (and use in the standard CDs) the use of OMOBJ for formulae in the OMCDs.

Please elaborate. It looks to me as if OMOBJ is already used as a container for OM-XML-encoded formulae in CDs?

Or are you thinking about CDs that are themselves encoded as OM objects? In that case, I might have been thinking much the same thing, and have been about to submit a proposal on the matter. If reasonably the same thing, it should probably be dealt with under the same ticket, whereas if quite different, then a separate ticket might be more in order.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 8-Oct-2013 6:01pm

Replying to [comment:1 lars_h]:

Replying to [ticket:145 kohlhase]:

We should allow (and use in the standard CDs) the use of OMOBJ for formulae in the OMCDs.

Please elaborate. It looks to me as if OMOBJ is already used as a container for OM-XML-encoded formulae in CDs?
Yes, in FMPs, but not in CMPs, look for instance in arith1.ocd, which contains (in a {{CMP}}}

<CMP>
  for all integers a,b |
  There does not exist a c>0 such that c/a is an Integer and c/b is an
  Integer and lcm(a,b) > c.
</CMP>

i.e. the math is given as ASCII art. I would like to replace c>0, c/a and friends with the respective OMOBJ elements, that would make the statements more precise. And then when we present CDs on the web, we can turn this into MathML, just like we do for the FMPs.

Note furthermore, that the formulae in the CMP are all sub-formulae for the corresponding FMP element, so we can even encode them by <OMOBJ><OMR xref="..."/></OMOBJ> given that we have ID attributes on the respective subformulae. This would save formalization and management effort.

Does this clarify my intention?

Or are you thinking about CDs that are themselves encoded as OM objects? In that case, I might have been thinking much the same thing, and have been about to submit a proposal on the matter. If reasonably the same thing, it should probably be dealt with under the same ticket, whereas if quite different, then a separate ticket might be more in order.
I think that is a completely different matter, and I frankly do not think that this is a good idea, so you should open another ticket.

[jbs1]

migrated from Trac, where originally posted by lars_h on 11-Oct-2013 8:51am

Replying to [comment:2 kohlhase]:

Replying to [comment:1 lars_h]:

Replying to [ticket:145 kohlhase]:

We should allow (and use in the standard CDs) the use of OMOBJ for formulae in the OMCDs.

Please elaborate. It looks to me as if OMOBJ is already used as a container for OM-XML-encoded formulae in CDs?
Yes, in FMPs, but not in CMPs, look for instance in arith1.ocd, which contains (in a {{CMP}}}
{{{

for all integers a,b |
There does not exist a c>0 such that c/a is an Integer and c/b is an
Integer and lcm(a,b) > c.

}}}
i.e. the math is given as ASCII art. I would like to replace c>0, c/a and friends with the respective OMOBJ elements, that would make the statements more precise. And then when we present CDs on the web, we can turn this into MathML, just like we do for the FMPs.

Thank you, that is much clearer. Not unreasonable, if used when appropriate.

Note furthermore, that the formulae in the CMP are all sub-formulae for the corresponding FMP element, so we can even encode them by <OMOBJ><OMR xref="..."/></OMOBJ> given that we have ID attributes on the respective subformulae. This would save formalization and management effort.

That would probably follow, but would it be a good thing? It would make .ocd files less human-readable than they already are, which is perhaps not a problem if one imagines that everyone rather views the .xhtml files on www.openmath.org, but that is not enough for those who need to create new content dictionaries (and probably don't have that rendering machinery at their disposal for their own writing): the more convoluted the coding style of the official CDs become, the more confusing will the task of contributing additional ones be.

In addition, this would allow for reducing every CMP to <CMP><OMOBJ><OMR xref="#corresponding_FMP"/></OMOBJ></CMP>, which goes directly against the guideline that every FMP should have a corresponding CMP — it's not the other way around! Maybe that guideline could do with being rethought, but it was probably introduced for a reason.

Or are you thinking about CDs that are themselves encoded as OM objects? In that case, I might have been thinking much the same thing, and have been about to submit a proposal on the matter. If reasonably the same thing, it should probably be dealt with under the same ticket, whereas if quite different, then a separate ticket might be more in order.
I think that is a completely different matter,

Agreed. I will return to it in a separate ticket (#147), then.

[jbs1]

migrated from Trac, where originally posted by lars_h on 19-May-2014 3:11pm

See also #11 (Mixed content for textual bits in CD descriptions).

The term "ASCII art" is often used in a mildly derogatory fashion, but I'd say there actually is merit in having content that can be immediately read by all humans concerned, even if it visually leaves much else to be desired. Maybe there should really be three different levels:

CMP::
Plain text that is immediately human-readable, but in all likelyhood not machine-readable.
FMP::
Machine-readable content, which however will require separate rendering or some effort for a human to read.
MMP (Mixed Mathematical Property)::
Text-with-markup which requires a human reader for interpretation, but which may first need to be preprocessed by some renderer in order to be easily understood. Markup may include (some subset of) XHTML(+MathML), but also inline OMOBJs to be converted to Presentation MathML or otherwise rendered. It could be argued that the text-or-om content of an element is already an example of this kind of thing, and that #11 asks for additional markup possibilities.

A problem with straight off allowing OMOBJ elements in CMPs is that an old renderer would likely be confused by them, which could result in it generating invalid output. Allowing it in a new container element would make it more likely that this new kind of mixed content is simply ignored by an old renderer, which IMHO is better than making a mess out of it.

Besides CMPs and Examples, CDs also contain text in Description and CDComment elements. Since Descriptions are analogous to abstracts, one could make a case that very general formatting abilities are actually not desired there.

[kohlhase]

moved to OpenMath/OMSTD#20