Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

markup for definienda and definienses #55

Open
kohlhase opened this issue Oct 5, 2017 · 11 comments
Open

markup for definienda and definienses #55

kohlhase opened this issue Oct 5, 2017 · 11 comments
Assignees

Comments

@kohlhase
Copy link
Member

kohlhase commented Oct 5, 2017

The OM Standard defines a couple of technical terms (e.g. bound and free, that set me off). and we currently use <quote>foo</quote> to mark up the definienda. It would be helpful to the reader, if we would have markup and interlinking for defined terms. I.e.

a <termdef id="foo">formal object ontology</termdef>, i.e a ....

and then later

we use the <termref href="foo">formal object ontology</termref> for 

The idea is that <termdef> becomes bold in the html and PDF and carries and anchor and the <termref> becomes a link to that "defining occurrence".

That would be relatively easy to implement in the conversion and I would be willing to add the markup.
cc: @JamesHDavenport @pdfion

@kohlhase
Copy link
Member Author

kohlhase commented Oct 5, 2017

BTW, i am counting 27 <quote>, so it might be worth it. And we have a similar linking in the RNC as well.

@davidcarlisle
Copy link
Member

we don't have to stick religiously to docbook now but I think the docbook way to have the term definitions as in our current

<varlistentry><term id="CDGroup"><systemitem>CDGroup</systemitem></term>

or for inline definintions

<termdef id="alpha">blah blah ... <firstterm>alpha conversion</firstterm> something or other. about variables..</termdef>

and then a link to the term being <xref termend="CDGroup"/>

although having looked up exactly what docbook suggests I am tempted do use more focussed markup as you suggest.

It would however be nice to make the existing definition lists using

<variablelist>
<varlistentry><term><systemitem>CDGroup</systemitem></term>
...

have anchors (either by giving them id= in the source or just implicitly taking the label as an anchor, that way you would be able to link directly to

https://openmath.github.io/standard/om20-editors-draft/omstd20#CDGroup

even if no reference in the doc goes straight to that item.

currently the nearest you can get to is the heading for the section containing the definition list

https://openmath.github.io/standard/om20-editors-draft/omstd20#sect_cdgpcdata

So....

do you need "inline" definitions for the first time, or do we stick with the current definition list style?
and either way do we force an explicit ID possibly or should we implicitly make an id out of the term (eg by lowercase and remove space).

davidcarlisle added a commit that referenced this issue Oct 7, 2017
@davidcarlisle
Copy link
Member

I went with some compromise between keeping docbook flavoured markup something understandable.

Implemented the following changes

<term> now optionally takes an id attribute and can appear in running text as well as in <varlistentry> the existing <xref linkend="id"/> markup now includes term in the element types it handles (along with sections, bibliography items etc) and typesets the body of the referenced term.

In html (not yet pdf) the term gets an id (on a new <span> for inline references, or on the existing <dt> in definition lists) and the reference is an <a class=termref href='#id> although currently no css styling specified for class termref,

So the meaningless input

<varlistentry><term id="ominteger">Integer</term><listitem><para>Arbitrary Precision
integers.</para> </listitem></varlistentry>
<varlistentry><term>Float</term><listitem> <para>&OM; floats are <xref linkend="ominteger"/>
<acronym>ieee</acronym> 754 Double precision floating-point
numbers. Other <term id="zz">types</term> of floating point number may be encoded in &OM;
by the use of suitable content dictionaries. <xref linkend="zz"/></para>

produces

<dt id="ominteger">Integer</dt><dd><p>Arbitrary Precision
integers.</p> </dd>
<dt>Float</dt><dd> <p><i>OpenMath</i> floats are <a href="#ominteger" class="termref">Integer</a>
<abbr>IEEE</abbr> 754 Double precision floating-point
numbers. Other <span id="zz">types</span> of floating point number may be encoded in <i>OpenMath</i>
by the use of suitable content dictionaries. <a href="#zz" class="termref">types</a></p>

@kohlhase
Copy link
Member Author

kohlhase commented Oct 7, 2017

excellent, then I will start using that systematically; I will probably make a branch and a pull request for that. But probably only after we have agreed on and merged the alpha-conversion PR #50.

@kohlhase kohlhase reopened this Dec 9, 2017
@kohlhase
Copy link
Member Author

kohlhase commented Dec 9, 2017

I find myself using xref with other (mostly plurals or inflected) link texts than the one inferred.
Could you extend this so that

<term id="attvar">attributed variable</term> .... <xref linkend="attvar">attributed variables</xref>

works? I believe that this should be relatively simple to do right?

@kohlhase kohlhase closed this as completed Dec 9, 2017
@kohlhase kohlhase reopened this Dec 9, 2017
@kohlhase
Copy link
Member Author

kohlhase commented Dec 9, 2017

Also I think we should have a class for "term with id" (which stands for a definiendum). Normally, such definienda are marked up in boldface. It would be great to have that for the OM standard as well.

@kohlhase
Copy link
Member Author

kohlhase commented Dec 9, 2017

Also I think we should have a class for "term with id" (which stands for a definiendum). Normally, such definienda are marked up in boldface. It would be great to have that for the OM standard as well.

Actually, I have started a new branch definition-markup (to be committed) and there I have fixed the css in the html. But not in the PDF.

@JamesHDavenport
Copy link
Contributor

JamesHDavenport commented Dec 9, 2017 via email

@car222222
Copy link
Collaborator

I also have some views on ‘definitions’, some of which may affect the work on ‘definition-markup’.

@car222222
Copy link
Collaborator

But maybe your new stuff is only relevant to the defining terms in the standard, rather than the ‘mathematical definitions’ in CDs.

@kohlhase
Copy link
Member Author

But maybe your new stuff is only relevant to the defining terms in the standard, rather than the ‘mathematical definitions’ in CDs.

yes, it is only editorial work on the standard. Definitions in CDs are a different matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants