Mixed content for textual bits in CD descriptions

[jbs1]

migrated from Trac, where originally posted by polx on 6-Nov-2007 11:12pm

It has been our experience that simple text is too often too small
to express and that the obvious web-rendering of CDs should take
advantage of links imperatively.

They should be possible within properties, examples, and comments.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 8-Nov-2007 12:40pm

We were discussing opening up the text format for CDs at the MathML F2F, and David cautioned that we need a short ASCII (i.e. without MathML) description of a symbol that can be displayed in a tooltip or so;\

We agreed that we should have two fields:

1. with short simple ASCII/UniCode text
2. with a subset of XHML+MathML

I have made a first suggestion in an experimental RNC for MCDs. That could then go into an extended CD format for OM3.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 23-Jan-2008 7:32am

We have and from the MathML CDs, and I have experimentally introduced a <Title> field to CDS for the ASCII stuff, this name seems better.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 23-Jan-2008 7:44am

David Carlisle had suggested to take the inline model of XHTML2 for this, I guess that he means the following modules

• XHTML Text Module
• XHTML Hypertext Module
• XHTML List Module
• XHTML Core Attributes Module
• XHTML Hypertext Attributes Module
• XHTML I18N Attribute Module
• XHTML Image Module
• XHTML Object Module

[jbs1]

migrated from Trac, where originally posted by polx on 23-Jan-2008 9:35am

Where would you put OpenMath inside there?

It has to be there, I think.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 23-Jan-2008 3:39pm

you are right, I had forgotten, we need to extend the inline model by OpenMath and MathML here.

[jbs1]

migrated from Trac, where originally posted by david on 29-Jan-2008 1:14am

Replying to [comment:11 kohlhase]:

I'm not sure that OM and MML should be inlined into he xhtml (not necessarily against it) traditionally openmath has been restricted to specific CD fields that were just openmath (FMP and friends) with descriptive text being in fields that did not have any OM (Description and friends).

We could allow a richer text markup (eg xhtml) without necessarily allowing OM.
CDUses and general consistency checking gets harder if we allow unconstrained use of OM in text fields. (Although some things might be easier to express...)

As for the content model I'd probably use less than all the models you listed in comment #8, no object for a start. Maybe just start small, I'd probably allow p (although it's not inline) because otherwise it's hard to make long comments without falling back on blank line syntaxes, and then perhaps just b i br lists and a.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 30-Jan-2008 4:47am

Replying to [comment:12 david]:

Replying to [comment:11 kohlhase]:

I'm not sure that OM and MML should be inlined into he xhtml (not necessarily against it) traditionally openmath has been restricted to specific CD fields that were just openmath (FMP and friends) with descriptive text being in fields that did not have any OM (Description and friends).
We talked about this before and it seemed that there were voices (Paul's, mine,...) that wanted to have some kind of Math in descriptive fields so that we can really say what we mean mathematically. The view is that descriptive fields should be rigorous math like in textbooks.

There were voices (your's,...) that were worried about universally being able to display CD material in e.g. tooltips,...

I thought that your suggestion to have two kinds of descriptive fields

• one short one for tooltips without embedded math
• one longer one for rigorous math vernacular with embedded mobj
  (the first one being mandatory, the second one being optional) was a very sensible compromise in this situation.

We could allow a richer text markup (eg xhtml) without necessarily allowing OM.
agreed, these are independent.
CDUses and general consistency checking gets harder if we allow unconstrained use of OM in text fields. (Although some things might be easier to express...)
I am not very worried about this, XPath and XSLT are really quite powerful :-)

As for the content model I'd probably use less than all the models you listed in comment #8, no object for a start. Maybe just start small, I'd probably allow p (although it's not inline) because otherwise it's hard to make long comments without falling back on blank line syntaxes, and then perhaps just b i br lists and a.
I probably agree with dropping object, but I think that image should be in there. Of course you could use now, but I would consider that as cheating semantically.
Another thing I realize, I think that we will need tables, and that somehow got dropped from my list above.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 25-Feb-2011 12:06pm

rescheduling

[jbs1]

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

See also #145 (Allow OMOBJ in OMCD texts).

[kohlhase]

moved to OpenMath/OMSTD#20