# inline markup wiki entry

**URL:** <https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628>\
**Category:** CSL Development\
**Created:** [April 30, 2009, 12:25pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628 "2009-04-30T12:25:34Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [April 30, 2009, 12:25pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/1 "2009-04-30T12:25:34Z")

</div>

To gather information on the inline stuff, I’ve created a wiki page.

[https://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup](https://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup)

We could use some more examples.

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 3, 2009, 3:49am UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/2 "2009-05-03T03:49:14Z")

</div>

> To gather information on the inline stuff, I’ve created a wiki page.
> 
> [XBib download | SourceForge.net](https://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup)
> 
> We could use some more examples.

I’ll try to add to the list sometime soon.

In citeproc-js, I’m thinking of implementing inline formatting as a  
facility configurable at runtime, with no fixed set of tags, to help  
folks cope while this issue develops. This will give a boost to  
people like Rintze (and probably many others) who have adopted private  
markup schemes in their Zotero databases. If the tags are  
configurable, it can be adapted to produce visuals from a semantic  
markup scheme, and passing semantic markup through for special  
purposes (RDFa) should be no problem, when things have settled down.

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 3, 2009, 2:19pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/3 "2009-05-03T14:19:32Z")

</div>

Can you add a specific proposal to the wiki?

Also, on RDFa, the main issue will be keeping track of URIs for  
different objects. But I think it a really good idea for people to  
think about this.

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 7, 2009, 11:31pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/4 "2009-05-07T23:31:18Z")

</div>

> Can you add a specific proposal to the wiki?
> 
> Also, on RDFa, the main issue will be keeping track of URIs for  
> different objects. But I think it a really good idea for people to  
> think about this.

I have implemented a mechanism for arbitrary wiki-style in-field  
markup in citeproc-js that may help reduce the barriers to support for  
semantic markup. I’ve added a proposal to the wiki that attempts to  
explain how I think it might be useful, with a link to the citeproc-js  
sources and a reference to the rpc-stuff demo.

Frank

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 8, 2009, 12:01am UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/5 "2009-05-08T00:01:38Z")

</div>

Frank,

> > Can you add a specific proposal to the wiki?
> > 
> > Also, on RDFa, the main issue will be keeping track of URIs for  
> > different objects. But I think it a really good idea for people to  
> > think about this.
> 
> I have implemented a mechanism for arbitrary wiki-style in-field  
> markup in citeproc-js that may help reduce the barriers to support for  
> semantic markup. I’ve added a proposal to the wiki that attempts to  
> explain how I think it might be useful, with a link to the citeproc-js  
> sources and a reference to the rpc-stuff demo.

I’m having a hard time understanding exactly what you’re proposing,  
and a) am really busy, and b) am running into this problem:

$ ./client.sh  
./results/config.result: No such file or directory  
wget exited with error … is server.py running?

The server _seems_ to be running, but am not really sure.

So aside from resolving this particular problem, can you just boil  
down the proposal?

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 8, 2009, 12:46am UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/6 "2009-05-08T00:46:45Z")

</div>

> Frank,
> 
> > > Can you add a specific proposal to the wiki?
> > > 
> > > Also, on RDFa, the main issue will be keeping track of URIs for  
> > > different objects. But I think it a really good idea for people to  
> > > think about this.
> > 
> > I have implemented a mechanism for arbitrary wiki-style in-field  
> > markup in citeproc-js that may help reduce the barriers to support for  
> > semantic markup. I’ve added a proposal to the wiki that attempts to  
> > explain how I think it might be useful, with a link to the citeproc-js  
> > sources and a reference to the rpc-stuff demo.
> 
> I’m having a hard time understanding exactly what you’re proposing,  
> and a) am really busy, and b) am running into this problem:
> 
> $ ./client.sh  
> ./results/config.result: No such file or directory  
> wget exited with error … is server.py running?
> 
> The server _seems_ to be running, but am not really sure.

Sorry about that. I’ve fixed the script, next time you check you can  
get it with pull and update.

> So aside from resolving this particular problem, can you just boil  
> down the proposal?

The idea is that a Zotero user should be able to go to Preferences and  
register a set of wiki markup strings for use with their database,  
associating each with a Zotero presentational function and an  
alternate (@font-style:italics/@font-style:normal,  
@quotes:true/@squotes:true, etc.). Multiple markup strings can be  
associated with the same presentational element.

This gets wiki visual markup going in a way that plays well with  
legacy databases (I’m thinking especially of Rintze here) – and since  
the local markup conventions are known to the processor, for RDF  
export, say, each marker can be converted to a semantic markup form.  
The exporting user would have to take care that the markup in the  
entries being exported actually lines up with the semantic  
association, but if that small pitfall is acceptable, this allows you  
to convert existing stores, and stores that people (inevitably) build  
with visual-only markup embedded in their records, into a standard  
form of semantic markup suitable for wider circulation and  
collaborative projects.

I hope that’s clear. The key point is that having a configurable  
syntax in Zotero would bring some happiness to people on both sides of  
the semantic/visual discussion, and open a low-cost path to building  
shared databases with true semantic markup in them.

Frank

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 8, 2009, 1:37pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/7 "2009-05-08T13:37:34Z")

</div>

…

> The idea is that a Zotero user should be able to go to Preferences and  
> register a set of wiki markup strings for use with their database,  
> associating each with a Zotero presentational function and an  
> alternate (@font-style:italics/@font-style:normal,  
> @quotes:true/@squotes:true, etc.). Multiple markup strings can be  
> associated with the same presentational element.

Right; I get that part. But a) citeproc-js can and should be agnostic  
about the application, and b) I just wasn’t of how this would work in  
practice.

> This gets wiki visual markup going in a way that plays well with  
> legacy databases (I’m thinking especially of Rintze here) – and since  
> the local markup conventions are known to the processor, for RDF  
> export, say, each marker can be converted to a semantic markup form.

OK, but how?

> The exporting user would have to take care that the markup in the  
> entries being exported actually lines up with the semantic  
> association, but if that small pitfall is acceptable, this allows you  
> to convert existing stores, and stores that people (inevitably) build  
> with visual-only markup embedded in their records, into a standard  
> form of semantic markup suitable for wider circulation and  
> collaborative projects.
> 
> I hope that’s clear. The key point is that having a configurable  
> syntax in Zotero would bring some happiness to people on both sides of  
> the semantic/visual discussion, and open a low-cost path to building  
> shared databases with true semantic markup in them.

Yes, but let’s forget about Zotero for a moment. Let’s say someone  
wants to build out your server example and have citations and  
bibliographies done as a web service. How would this work? What input  
would they get? How does it get mapped to a particular output?

Also, are you saying we offer no attempt to define any standard  
semantic micro-structures?

I’m sure you’ve thought about this; it just hasn’t translated into  
text that my brain can process 🙂

Bruce

---

<div class="post-metadata">

**Author:** ![Rintze\_Zelle](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/rintze_zelle/32/175_2.png) [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)\
**Post date:** [May 8, 2009, 2:50pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/8 "2009-05-08T14:50:08Z")

</div>

> Also, are you saying we offer no attempt to define any standard  
> semantic micro-structures?

Your main (or even only?) goal for using semantic markup is to get correct  
presentational markup between different styles, right? Which is needed when  
there is some semantic-dependent variation in the desired presentational  
markup between styles?

I was wondering whether it would make sense to separate semantic and  
presentational markup somewhat, at least for the chemical/genetic  
nomenclature, thus allowing for more coarse semantics. This

L-[methyl-14C]methionine

would require much less detailed semantic information than

L\</chemical-enantiomere

> -[methyl\</chemical-sidegroup  
> -14C\</chemical-isotope  
> ]methionine

and would allow chemical-markup to be handled differently from e.g.  
quote-markup.

Rintze\>

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 8, 2009, 2:56pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/9 "2009-05-08T14:56:11Z")

</div>

Whoa; just to be clear, I am NOT suggesting inventing a new XML  
micro-language for this. Am suggesting using (X)HTML.

Am busy, but a quick example (e.g. the details are surely wrong) could  
theoretically be:

L-[methyl-14c]

One could also imagine standard presentational classes (“italic”, “bold”, etc.).

Bruce

---

<div class="post-metadata">

**Author:** ![Rintze\_Zelle](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/rintze_zelle/32/175_2.png) [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)\
**Post date:** [May 8, 2009, 3:12pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/10 "2009-05-08T15:12:01Z")

</div>

> Whoa; just to be clear, I am NOT suggesting inventing a new XML  
> micro-language for this.

Neither was I (sorry for my botched attempt to explain myself).

> Am suggesting using (X)HTML.
> 
> Am busy, but a quick example (e.g. the details are surely wrong) could  
> theoretically be:
> 
> L-[methyl-14c]
> 
> One could also imagine standard presentational classes (“italic”, “bold”,  
> etc.).

My point was more that, if all you need is to distinguish chemistry-markup  
as a group from e.g. quote-markup (which I think is enough in (almost) all  
cases), I wouldn’t want to put the significant burden on the user to go into  
the nitty-gritty details on how to properly markup the chemical names in the  
titles of his/her library semantically (if you look at the title of a paper,  
a layman can see how it is formatted presentationally, but it would require  
a significant amount of knowledge about chemistry to see how that  
presentational markup represents semantic information). Just putting the  
whole chemical-name in a tag would be enough, and pure presentational tags  
could be used inside the tagged chemical-name to identify the individual  
parts that require markup. It would also greatly simplify the total amount  
of classes that are required.

Rintze

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 8, 2009, 3:27pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/11 "2009-05-08T15:27:23Z")

</div>

Yes, that’s fine. I agree any semantic content should be optional.

I’m just wondering if, if we agree on that, what the optional content  
should be. It sounds like Frank was saying we don’t care; totally up  
to the user.

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 8, 2009, 11:39pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/12 "2009-05-08T23:39:46Z")

</div>

> …
> 
> > The idea is that a Zotero user should be able to go to Preferences and  
> > register a set of wiki markup strings for use with their database,  
> > associating each with a Zotero presentational function and an  
> > alternate (@font-style:italics/@font-style:normal,  
> > @quotes:true/@squotes:true, etc.). Multiple markup strings can be  
> > associated with the same presentational element.
> 
> Right; I get that part. But a) citeproc-js can and should be agnostic  
> about the application, and b) I just wasn’t of how this would work in  
> practice.
> 
> > This gets wiki visual markup going in a way that plays well with  
> > legacy databases (I’m thinking especially of Rintze here) – and since  
> > the local markup conventions are known to the processor, for RDF  
> > export, say, each marker can be converted to a semantic markup form.
> 
> OK, but how?
> 
> > The exporting user would have to take care that the markup in the  
> > entries being exported actually lines up with the semantic  
> > association, but if that small pitfall is acceptable, this allows you  
> > to convert existing stores, and stores that people (inevitably) build  
> > with visual-only markup embedded in their records, into a standard  
> > form of semantic markup suitable for wider circulation and  
> > collaborative projects.
> > 
> > I hope that’s clear. The key point is that having a configurable  
> > syntax in Zotero would bring some happiness to people on both sides of  
> > the semantic/visual discussion, and open a low-cost path to building  
> > shared databases with true semantic markup in them.
> 
> Yes, but let’s forget about Zotero for a moment. Let’s say someone  
> wants to build out your server example and have citations and  
> bibliographies done as a web service. How would this work? What input  
> would they get? How does it get mapped to a particular output?
> 
> Also, are you saying we offer no attempt to define any standard  
> semantic micro-structures?
> 
> I’m sure you’ve thought about this; it just hasn’t translated into  
> text that my brain can process 🙂

Clarity is not my strong suit. 🙂

I’ll doodle up an illustration of the workflow I have in mind and put  
it on the wiki. We do care that the data end up with a uniform markup  
scheme when it is shared between users; the idea is to create a  
funnel, so that diverse markup patterns can be migrated via the  
processor to that unified scheme.

Coming soon …

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 11, 2009, 12:34am UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/13 "2009-05-11T00:34:59Z")

</div>

> > …
> > 
> > > The idea is that a Zotero user should be able to go to Preferences and  
> > > register a set of wiki markup strings for use with their database,  
> > > associating each with a Zotero presentational function and an  
> > > alternate (@font-style:italics/@font-style:normal,  
> > > @quotes:true/@squotes:true, etc.). Multiple markup strings can be  
> > > associated with the same presentational element.
> > 
> > Right; I get that part. But a) citeproc-js can and should be agnostic  
> > about the application, and b) I just wasn’t of how this would work in  
> > practice.
> > 
> > > This gets wiki visual markup going in a way that plays well with  
> > > legacy databases (I’m thinking especially of Rintze here) – and since  
> > > the local markup conventions are known to the processor, for RDF  
> > > export, say, each marker can be converted to a semantic markup form.
> > 
> > OK, but how?
> > 
> > > The exporting user would have to take care that the markup in the  
> > > entries being exported actually lines up with the semantic  
> > > association, but if that small pitfall is acceptable, this allows you  
> > > to convert existing stores, and stores that people (inevitably) build  
> > > with visual-only markup embedded in their records, into a standard  
> > > form of semantic markup suitable for wider circulation and  
> > > collaborative projects.
> > > 
> > > I hope that’s clear. The key point is that having a configurable  
> > > syntax in Zotero would bring some happiness to people on both sides of  
> > > the semantic/visual discussion, and open a low-cost path to building  
> > > shared databases with true semantic markup in them.
> > 
> > Yes, but let’s forget about Zotero for a moment. Let’s say someone  
> > wants to build out your server example and have citations and  
> > bibliographies done as a web service. How would this work? What input  
> > would they get? How does it get mapped to a particular output?
> > 
> > Also, are you saying we offer no attempt to define any standard  
> > semantic micro-structures?
> > 
> > I’m sure you’ve thought about this; it just hasn’t translated into  
> > text that my brain can process 🙂
> 
> Clarity is not my strong suit. 🙂
> 
> I’ll doodle up an illustration of the workflow I have in mind and put  
> it on the wiki. We do care that the data end up with a uniform markup  
> scheme when it is shared between users; the idea is to create a  
> funnel, so that diverse markup patterns can be migrated via the  
> processor to that unified scheme.
> 
> Coming soon …

I’ve begun building a set of illustrations on the wiki:

[XBib download | SourceForge.net](http://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup)

I will carry forward and lay out how the workflow of a configurable  
wiki syntax mechanism would work, but there’s enough there to  
illustrate the problem that I see emerging with the introduction of  
inline markup.

The next step can be summarized very simply, as analogous to the mess  
with code pages and other character encoding hacks, when the time came  
to map them onto Unicode. A CSL inline markup processor essentially  
needs to be able to do the same thing, but mapping from arbitrary ad  
hoc user-defined markup arrangements to a standard scheme. If it has  
that ability, you can get out in front of the problem and provide a  
smooth migration path.

The result will not be perfect uniformity, but if you have a  
demonstrated mechanism in place of _producing_ uniformity, and a model  
for what it should look like, then you can forestall vendors from  
deploying proprietary markup, if and when semantic markup becomes the  
Next Big Thing — and they can be trusted to do exactly that. For an  
egregious example involving our friends at Thomson Reuters, see West  
Pub. Co. v. Mead Data Cent., Inc., 616 F. Supp. 1571 (D. Minn. 1985),  
aff’d, 799 F.2d 1219 (8th Cir.), cert. denied, 479 U.S. 1070 (1986):

[Westlaw - Wikipedia](http://en.wikipedia.org/wiki/Westlaw#Legal_disputes)

(As I’ve said before, not nice people.)

More coming, but that’s the line of reasoning.

Frank

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 11, 2009, 1:00pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/14 "2009-05-11T13:00:19Z")

</div>

> I’ve begun building a set of illustrations on the wiki:
> 
> [XBib download | SourceForge.net](http://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup)
> 
> I will carry forward and lay out how the workflow of a configurable  
> wiki syntax mechanism would work, but there’s enough there to  
> illustrate the problem that I see emerging with the introduction of  
> inline markup.

Yes.

> The next step can be summarized very simply, as analogous to the mess  
> with code pages and other character encoding hacks, when the time came  
> to map them onto Unicode. A CSL inline markup processor essentially  
> needs to be able to do the same thing, but mapping from arbitrary ad  
> hoc user-defined markup arrangements to a standard scheme. If it has  
> that ability, you can get out in front of the problem and provide a  
> smooth migration path.

But it remains an open question whether the normalization happens at  
the CSL stage, and whether user’s really get the choice to invent  
their own markups.

For sake of argument, applications like Zotero could invent schemes  
that only work through the GUI. Imagine a contextual-menu item  
populated with a preset numbers of class items, with the ability of  
the user to add new ones. Maybe those can get optional keyboard  
bindings.

That offers the same advantages to users, but allows us to say “we  
only accept inline markup of X form.” It also solves data  
import/export problems.

…

> More coming, but that’s the line of reasoning.

Yeah, I’m not yet seeing the precise proposal vis-a-vis CSL 😉

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 11, 2009, 1:39pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/15 "2009-05-11T13:39:27Z")

</div>

> > I’ve begun building a set of illustrations on the wiki:
> > 
> > [XBib download | SourceForge.net](http://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup)
> > 
> > I will carry forward and lay out how the workflow of a configurable  
> > wiki syntax mechanism would work, but there’s enough there to  
> > illustrate the problem that I see emerging with the introduction of  
> > inline markup.
> 
> Yes.
> 
> > The next step can be summarized very simply, as analogous to the mess  
> > with code pages and other character encoding hacks, when the time came  
> > to map them onto Unicode. A CSL inline markup processor essentially  
> > needs to be able to do the same thing, but mapping from arbitrary ad  
> > hoc user-defined markup arrangements to a standard scheme. If it has  
> > that ability, you can get out in front of the problem and provide a  
> > smooth migration path.
> 
> But it remains an open question whether the normalization happens at  
> the CSL stage,

I thought I made that one clear. At the moment, it’s a choice of  
Zotero+Mendeley+pandoc, or  
Word+OpenOffice+WordForMac+various-scripting-languages,  
or the CSL processor. Which of those three categories has a single  
mailing list via which  
you can request comments from all of the developers involved?

> and whether user’s really get the choice to invent  
> their own markups.

They already have.

> For sake of argument, applications like Zotero could invent schemes  
> that only work through the GUI. Imagine a contextual-menu item  
> populated with a preset numbers of class items, with the ability of  
> the user to add new ones. Maybe those can get optional keyboard  
> bindings.

That would be great, but not all CSL deployments have a graphical  
UI and pulldown menus.

> That offers the same advantages to users, but allows us to say “we  
> only accept inline markup of X form.” It also solves data  
> import/export problems.

If the processor is fully configurable for markup, any engine  
that wanted to control it in that way could do so. But if the processor  
is fully configurable, it’s not necessary to impose restrictions that strand  
users who have legacy markup schemes in their existing databases.

> …
> 
> > More coming, but that’s the line of reasoning.
> 
> Yeah, I’m not yet seeing the precise proposal vis-a-vis CSL 😉

All things with time. 🙂 I’m kind of busy myself at the moment.

Frank

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [May 11, 2009, 2:17pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/16 "2009-05-11T14:17:45Z")

</div>

…

> > But it remains an open question whether the normalization happens at  
> > the CSL stage,
> 
> I thought I made that one clear. At the moment, it’s a choice of  
> Zotero+Mendeley+pandoc, or  
> Word+OpenOffice+WordForMac+various-scripting-languages,  
> or the CSL processor. Which of those three categories has a single  
> mailing list via which  
> you can request comments from all of the developers involved?

Well, we could say “CSL accepts X” and leave it to the application to  
create that representation.

I’m not saying I’m advocating it; just that it’s an obvious option.

> > and whether user’s really get the choice to invent  
> > their own markups.
> 
> They already have.
> 
> > For sake of argument, applications like Zotero could invent schemes  
> > that only work through the GUI. Imagine a contextual-menu item  
> > populated with a preset numbers of class items, with the ability of  
> > the user to add new ones. Maybe those can get optional keyboard  
> > bindings.
> 
> That would be great, but not all CSL deployments have a graphical  
> UI and pulldown menus.

Right, but does it matter?

I definitely prefer writing in emacs and using something like pandoc,  
so I’m not forgetting that use case; just saying that it can be up to  
Andrea what he expects. He just needs to know how it should interact  
with CSL.

> > That offers the same advantages to users, but allows us to say “we  
> > only accept inline markup of X form.” It also solves data  
> > import/export problems.
> 
> If the processor is fully configurable for markup, any engine  
> that wanted to control it in that way could do so. But if the processor  
> is fully configurable, it’s not necessary to impose restrictions that strand  
> users who have legacy markup schemes in their existing databases.

But you would admit that adding this kind of configuration (any  
really) has costs; right? While one or two people have requested it,  
for example, we don’t allow people to invent arbitrary new variables  
and types in CSL because doing so would impose a lot of pain.

In any case, I’ll have to wait to see your proposal.

> > > More coming, but that’s the line of reasoning.
> > 
> > Yeah, I’m not yet seeing the precise proposal vis-a-vis CSL 😉
> 
> All things with time. 🙂 I’m kind of busy myself at the moment.

Same here. No rush on my end. We’ve still got a couple months to figure it out.

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 11, 2009, 9:19pm UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/17 "2009-05-11T21:19:33Z")

</div>

> …
> 
> > > But it remains an open question whether the normalization happens at  
> > > the CSL stage,
> > 
> > I thought I made that one clear. At the moment, it’s a choice of  
> > Zotero+Mendeley+pandoc, or  
> > Word+OpenOffice+WordForMac+various-scripting-languages,  
> > or the CSL processor. Which of those three categories has a single  
> > mailing list via which  
> > you can request comments from all of the developers involved?
> 
> Well, we could say “CSL accepts X” and leave it to the application to  
> create that representation.
> 
> I’m not saying I’m advocating it; just that it’s an obvious option.
> 
> > > and whether user’s really get the choice to invent  
> > > their own markups.
> > 
> > They already have.
> > 
> > > For sake of argument, applications like Zotero could invent schemes  
> > > that only work through the GUI. Imagine a contextual-menu item  
> > > populated with a preset numbers of class items, with the ability of  
> > > the user to add new ones. Maybe those can get optional keyboard  
> > > bindings.
> > 
> > That would be great, but not all CSL deployments have a graphical  
> > UI and pulldown menus.
> 
> Right, but does it matter?
> 
> I definitely prefer writing in emacs and using something like pandoc,  
> so I’m not forgetting that use case; just saying that it can be up to  
> Andrea what he expects. He just needs to know how it should interact  
> with CSL.
> 
> > > That offers the same advantages to users, but allows us to say “we  
> > > only accept inline markup of X form.” It also solves data  
> > > import/export problems.
> > 
> > If the processor is fully configurable for markup, any engine  
> > that wanted to control it in that way could do so. But if the processor  
> > is fully configurable, it’s not necessary to impose restrictions that strand  
> > users who have legacy markup schemes in their existing databases.
> 
> But you would admit that adding this kind of configuration (any  
> really) has costs; right? While one or two people have requested it,  
> for example, we don’t allow people to invent arbitrary new variables  
> and types in CSL because doing so would impose a lot of pain.
> 
> In any case, I’ll have to wait to see your proposal.

Okay, I’m starting to get this into focus. The flip-flop code that  
I’ve written could as easily form part of a pre-processing chain in  
Zotero for the normalization of legacy data. I don’t want this  
sub-mechanism to be a distraction from the task of settling the core  
markup, so I’ll move the “Proposal #2” content to the citeproc-js  
wiki.

Frank

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [May 12, 2009, 1:12am UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/18 "2009-05-12T01:12:33Z")

</div>

> > I’ve begun building a set of illustrations on the wiki:
> > 
> > [XBib download | SourceForge.net](http://apps.sourceforge.net/trac/xbiblio/wiki/InlineMarkup)
> > 
> > I will carry forward and lay out how the workflow of a configurable  
> > wiki syntax mechanism would work, but there’s enough there to  
> > illustrate the problem that I see emerging with the introduction of  
> > inline markup.
> 
> Yes.
> 
> > The next step can be summarized very simply, as analogous to the mess  
> > with code pages and other character encoding hacks, when the time came  
> > to map them onto Unicode. A CSL inline markup processor essentially  
> > needs to be able to do the same thing, but mapping from arbitrary ad  
> > hoc user-defined markup arrangements to a standard scheme. If it has  
> > that ability, you can get out in front of the problem and provide a  
> > smooth migration path.
> 
> But it remains an open question whether the normalization happens at  
> the CSL stage, and whether user’s really get the choice to invent  
> their own markups.
> 
> For sake of argument, applications like Zotero could invent schemes  
> that only work through the GUI. Imagine a contextual-menu item  
> populated with a preset numbers of class items, with the ability of  
> the user to add new ones. Maybe those can get optional keyboard  
> bindings.

Looking back, I confess to getting confused at this point. If the purpose of  
semantic classes is to allow an element to be rendered differently in  
different styles, how does the style know what presentation to associate  
with a user-defined element? That will need to be known at some point  
in the chain, and for RTF, it needs to be known to the CSL processor.

Wouldn’t it be better to offer a set of semantic labels for a few elements  
that either have special significance for indexing and linking (like chemical  
names) or which may render differently in different styles (like titles),  
and a set of purely presentational tags, and leave it at that? Then if  
a user gets stuck for a need to render differently to different publications,  
they can work around it short term with presentation markup, and when they  
complain you can add a fresh semantic tag to CSL to cover their use case.

That would give you a predictable central store of known semantic elements,  
which style authors could map to appropriate presentation. The  
semantic → presentation mapping should be controlled at the style  
level, it seems to me.

---

<div class="post-metadata">

**Author:** ![Simon\_Kornblith](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Simon\_Kornblith](https://discourse.citationstyles.org/u/Simon_Kornblith)\
**Post date:** [May 12, 2009, 2:48am UTC](https://discourse.citationstyles.org/t/inline-markup-wiki-entry/628/19 "2009-05-12T02:48:43Z")

</div>

I haven’t been following this thread too closely, but I think the  
restricted label set approach is best. I can think of ways of  
implementing an extensible approach elegantly in Zotero, but I don’t  
really think it’s worth the effort. For one, what’s not covered by a  
restricted approach at any given time would likely be fringe use  
cases, and the UI implementation cost would likely outweigh its  
utility. Additionally, if the URIs (or identifiers of another sort)  
that are used to specify semantic labels aren’t normalized, they’re  
not particularly useful anyway. In either case, it seems absolutely  
vital that CSL specify some normative set of labels along with default  
presentational styles (and maybe associated markup syntax).

Simon