[om] Content Dictionaries vs. XSLT, Schema & Namespaces

[Jimmy Cerra]

Hey all.  I have an idea (1)!

Unlike MathML, OpenMath's mathematical vocabulary (2) can be expanded through
private-content dictionaries (CD).  However, unlike the official-CDs, these
private-CDs cannot be understood by 3rd party phrasebooks (3) in general (4).

My solution to the above is to use namespaces, schema and XSLT (NS&X) to extend
the markup in XML documents of OpenMath (5).  Obviously, NS&X cannot be applied
to the binary (and other) encodings of the language (6).  Furthermore, only
OpenMath programs that recognize NS&X can take advantage of this method.  Here's
how one would make an extension:

A) Define a CD for reference for the new vocabulary of symbols.  This provides a
standard reference for authors using the CD.

B) Link to the CD using a namespace in the OpenMath document.  Use a namespace
prefix when creating an instance of a namespace (to prevent conflicts with the
official CDs).  The prefix can be of the OpenMath document author's choosing.
This linking scheme offers more flexibility than the '<OMS cd="..." name="..."
/>' method (7).

C) Define a schema for the namespace.  This allows for syntax checking and
validation by a schema-aware processor.  (This is one major point for using this
method.)

d) Define an XSLT that transforms the custom elements into markup defined by
official-CDs.  If the CDs contain the basic 'primitive types' of mathematics,
then this process allows 3rd-party phrasebooks to interpret and understand the
foreign markup.  However, care must be made to specify what transformations to
make under what media type of the calling phrasebook - such as electronic
programs (like Mathematica), screen, Braille, speech, dead trees and etcetera.
Further care must be made not to reference any other private-CDs (8).

The above coding conventions would provide the same functionality as OpenMath
CDs.  However, they provide enhanced portability (among 3rd-party processors),
authoring style (more user/author-friendly; small OpenMath documents can be
quickly and safely encoded by hand - a common complaint among OpenMath critics)
and power (validation of foreign vocabularies; a standard, more
"machine-friendly" and precise for authors to encode "the mathematics" of the
foreign symbols).

What do ya thunk?

---
Jimmy Cerra

P.S. Trying this again.... Is the mail server working???

---
Notes and queries:

---
1:= (Oh no, another idea...) I originally thought about this as an extension to
MathML on their mailing list; URL=
http://lists.w3.org/Archives/Public/www-math/2002Apr/0070.html .  Then people
pointed to OpenMath since, "(my) "modules" idea corresponds closely to openmath
content dictionaries."  That's why I decided to bother you with these half-crazy
ideas (lucky you ;).

---
2:= I found a possible error in the spec.  Chapter 5, section 5.1 and paragraph
4 (on page 26 of the PDF), it states, 'With a set of symbol definitions (perhaps
from several content Dictionaries, A and B can now talk in a common "language".'
Shouldn't 'language' be 'vocabulary' since the CDs define a group of "words"
(see previous paragraph in the spec)?  Furthermore, should the word, content,
have its first letter capitalized (since the word, Dictionaries, is)?

---
3:= Question: Is a phrasebook something like a MathML processor?

---
4:= From a private e-mail: "...openmath dictionaries are essentially a
specification of the semantics, they may be formally specified (in openmath for
example) or it may just be defined by reference to a book."

---
5:= Hence, I suggest that the "eXtensible" in eXtensible Markup Language be used
more. :)

---
6:= That means that my idea will be more useful when using MathML.

---
7:= By using namespaces, elements (symbols) would be encoded as '<nsp:elname
prop1="..." prop2="..." />', where 'nsp' is the namespace prefix, 'elname' is
the element's name, and 'prop1' and 'prop2' are attributes.  This is easier to
read, as an author, than the encoding in OpenMath.  Furthermore, this allows the
elements and properties to be validated with a schema.  Also, this makes DOM
parsing more 'natural'.

---
8:= An infinite loop could occur if two XSLT sheets referenced each other.  This
restriction prevents that.

---
9:= ...and negative attributes... :)



--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems