We have to sign all sorts of paperwork, it turns out.
My name's James Cummings, and this
is the panel on the future directions of TI-ODD,
which Lou will explain to you in a few minutes.
The one of the reasons we're having this panel
is as a lead-in to a meeting that we're having on Saturday.
So if any of you are around on Saturday
and want to come and think theoretically
about where ODD should go in the future
and how we should develop it to make
it more resilient and better for even more bizarre uses,
then that is in the West Wing building in room 222,
starting at 9 AM on Saturday.
We're going to have a whole panel of people,
and I'm going to introduce them all to start with,
because that makes my job easier.
And we're going to start with Lou Bernard from TJA Adonis,
who's going to talk to us about the history of ODD
and the evolution of it, as you can see on the screen.
We're then going to have Sebastian Raatz from Oxford
talking about the processing of ODD
and chaining ODDs together and things like that.
We're then going to have Bert Van Geef down on the end,
from Atyleth, who will talk to us about classes and model
classes in ODD.
We're then going to have Sid Bauman here
from Brown University in the States,
who will talk to us about co-occurrence and things
like that.
And then we have a joint paper delivered by Laurent Romari
from INRIA, but also with Piotr Brabanski from HUB
talking about ODD for foreigners, ODD from scratch,
creating ODDs.
Lou.
Thank you, James.
I'm going to be as quick as I can.
I am making just a few assumptions
about what ODD means.
I will keep my eyes open, and if I
see people looking really baffled,
I will try to explain.
But I have a lot of material to cover,
so I assume a certain.
I don't think you'd have come to this session
if you hadn't heard of the TEI, right?
No but it looks good, OK.
And I'm guessing if you've heard of the TEI,
you've probably heard of the pizza chef, probably,
and you've probably heard of Roma, possibly.
OK, anyway.
How do you make this work, like that?
So one of the penalties of being very, very, very, very old,
like me, is that you can remember stuff that
happened a long time ago.
And that wasn't what I meant to do.
OK, so right at the beginning, well
before the end of the 20th century,
the TEI was already thinking, oh, stop it.
Why does it do that, Sid?
It's trying to make me go faster.
Stop it.
OK, I'm not touching anything.
I swear to God, I'm not touching anything.
You see?
Look, no hands.
All right, let's start again.
PDF display.
Well, maybe that's what I don't want.
I think slideshow suggests to me that it's
going to do a slideshow.
So shoot me.
Where was it?
View.
PDF display.
I'm going to try that.
If it's not already apparent, I'm a Unix person.
Single page.
Sidebar?
What was the sidebar?
I'll stay there.
Sorry about that.
I hate it when that happens.
I hate it when I'm in the audience when that happens,
and I hate it even more when I'm on the podium when that happens.
No, this isn't working.
God damn it.
Let's go back to where we were.
Let's try slide studio once more.
OK, now, let's see if nothing happens.
Good.
OK.
I do apologize, ladies and gentlemen.
Mr. Chairman, that doesn't count.
The TI began with a very conscious attempt
to model existing and future markup systems.
I well remember spending large amounts of time,
mostly, in fact, in Luxembourg City,
wandering around with Michael Spover McQueen,
trying to, first of all, see if we had a common understanding
about what text was, because we knew
that we were going to work on something called text encoding.
We both have backgrounds in database design.
We both had ideas about what markup did to a text
when you added it, what its function was.
Not as well formalized as other people have done after that,
but we already were developing a model.
And this little diagram I've copied here
from a paper which is still available,
both on Michael's own personal website
and also from the TEI Vault, has a little diagram that says,
clearly, we thought there are things called features of texts.
We use the word features in a very loose way
to mean abstract concepts that are, in some sense, present.
We're both nominalists in a document,
and which can be represented by tags that are introduced
into a document.
And there may be many different tags representing
the same concept.
And equally, the same tag might have many different names.
And that's what you see going on at the top of this diagram.
Equally, we could see that there were things for which we might
call markup languages nowadays that consist of sets of tags
and, correspondingly, sets of names going one way
and going the other way, sets of features
that those tags represent.
And equally, this, of course, is in 1989,
so long before the invention of the web.
Equally, of course, in those days,
there were many different syntaxes or different markup
syntaxes existed.
People represented the same sets of features in different ways
and gave them different names, which
is quite a useful background, because that
was what defined for us.
That, I think, is what's at the heart of odd, as it now is,
this perception of these concepts which
are based primarily on the idea that it
is possible to talk about a text, about a system of markup,
in abstract terms, independently of the way
that markup is realized.
We started enumerating the properties
of these various things, and that's far too small for you
to read, so I recommend that you go and read
the original document instead.
And we, as I said, we had backgrounds in databases.
So our first thought was, so what we'll do
is we'll make a database, and we'll
list all of these features and all the corresponding tags
in all the available markup languages,
and then we'll crunch it all up and somehow simplify it
and standardize it.
So we started identifying the properties of tags and markup
systems, and on this list we have
things like the tag name, the full name, the equivalent tags,
the feature that this thing is supposed to be marking up,
a wonderful one called binding, which is saying,
is the feature bound, unbound, or bindable?
That means, does this feature always appear in the same place
or could be made to appear in the same place
or can appear anywhere, and so on?
So a list of things like that, and this really
is the distant ancestor of odd, emerging
from the primeval slime and taking its first hesitant steps
on land.
Then, of course, during the early 90s,
reality started to enter our discussions as a result
of the fact that the TEI's work groups started sending in
their proposals for things that should be standardized
in the TEI guidelines.
And it soon became apparent that we
needed something a bit more sophisticated
than a relational database to keep track of what
they were inventing.
Because a lot of the way in which these scholars worked,
just as they do today, was to write elaborate prose explaining
exactly what the concept that this markup they needed
was meant to describe.
And so we needed something that combined
these informal, human-readable specifications
with a formal specification that carried all of those features
I've just enumerated.
Thank heavens Donald Knuth had been here before us.
You all, I hope, have heard of Donald Knuth, at least,
the inventor of lay-tech at TEI, sorry,
the inventor of TEI, the mathematical typesetting
language, who had this brilliant idea that the best way to write
and to make sure that people used it successfully,
a piece of software, was to combine in a single source
the source code itself in a formal language,
such as C or Fortran, even, and the documentation of it
so that you could imagine automatic processes that
kept the two in step and extracted the one that
was needed for a particular purpose.
And our idea was to re-express that model in, at that time,
SGML.
And here's a picture of the birthplace of Odd,
which is a cafe looking out over the marvelous fish market in Bergen.
And I was very pleased when I looked this up on TripAdvisor
to read the little comments at the bottom.
I don't know if you can read it.
It says, nice food and lovely people there.
The tablecloth is replaced with two big sheets of blank paper.
And you can doodle whatever you like.
And this is a comment somebody made in March this year.
And I'm really pleased to see this because, of course,
that was also true in 1991.
And so Michael and I sat at this table having lunch eating fish.
And there were two huge sheets of paper on the table.
There's a tablecloth.
And there was also, you can't see them in the picture,
but those little pots on the tables are full of wanks crayons.
And obviously, they're intended to keep the children quiet.
So they don't, you know.
But they were still there then.
And so Michael and I set to work.
And we produced a diagram of what we were going to base,
which became odd.
And there's a lot to say about this diagram.
And you can't see it at all, can you?
Can you?
Is it visible at all?
It's a very interesting diagram.
Sid, when he saw this, said, oh, but this can't be right
because it's dated 1991.
And it uses the words web and RDF.
Well, it is definitely dated contemporaneously.
Up in the top right, there is an annotation
made by Michael using his fountain pen,
I remember it well, which gives the date of the 23rd of November,
1991, and his signature in mind to prove it.
So this is a manuscript that is self-dating,
a rare and wonderful thing.
It shows, however, the heart of this diagram,
the reason I'm showing it to you,
is because it makes clear how odd was originally thought of
as the big blue circle in the middle, which is here.
And from it, you can see a whole number
of other things coming out.
And odd was originally conceived as being
the central SGML representation from which
a number of other formats might be derived.
And there's a long list of words.
Sorry, I realize now I could give the entire talk
on the basis of this invisible slide, so I won't.
The full specification for odd is also
available from the TEI's vault.
A couple of interesting things.
It defines itself as a set of extensions
to the existing so-called tiny DTD, which
was the first DTD we ever wrote to document
the structure of the TEI guidelines, which
was kind of a very light version of TEI lights
before TEI light existed.
But in the way that every other odd system ever since has done,
it added several new elements.
And those elements were intended to document
SGML fragments, elements, and entities.
And it also specifies how processes
are meant to behave in order to take those SGML elements
and extract properly formed bits of DTD language,
reference documentation, running prose.
And there was also another processor
to do the opposite thing, i.e.
generate default specifications starting from a DTD itself.
In those days, there were giants in the land,
and we wrote DTDs by hand.
It's amazing to realize that this document was actually
intended originally for the use of TEI work groups.
People like you were meant to read this document
and figure out how to produce specifications
that the editors, Michael and I, could then use.
This didn't always work, let's be honest.
Anyway, that's the beginning of the document, which again,
you can't see.
Odd was a production tool.
We used it for, this is version one,
we used it for several years.
And although it was really very useful,
it didn't actually set the world alight.
We presented it to an earlier version of this conference
held in Paris, but we never got around
to writing it up properly.
And maybe the fact that we put most of our emphasis
in presenting it on the way you could use it
to generate multiple outputs, which was really cool
in those days, the fact that you could take
a single SGML document and apply a different processor
to it, apply a processor to it and get a different output
each time or different format, that was the thing
that really we thought was pretty cool.
What we didn't really worry about was the fact
that writing SGML processors is not trivial.
Even in those days, it wasn't trivial.
We also really didn't realize that what we had here
was something that was much more useful than simply
Pandora's system for converting from one thing to another.
So I've got some slides here that talk about
the actual toolkit, which is probably not very interesting,
so I'll skip over that for the moment
and move on to the second generation node,
which is more or less where we are now.
Because of course, we've fast forwarded about 10 years
and suddenly there's a whole new range of tools available,
in particular XML tools and new more powerful schema
languages, notably RelaxNG.
These give you also, as well as these tools,
these tools are part of a much better, more flexible,
more powerful technical infrastructure.
So we have, Unicode is available,
so an awful lot of what was necessary in P1 and P2
and even P3 becomes totally unnecessary.
There is now a W3C, which there wasn't when we started,
and there is now a W3C pointer mechanism recommendation
which we could use and appropriate.
Lots of other people have entered the same playground
and are producing interesting systems
that we can appropriate for use within the TEI.
Some specifics, which became much more significant
in later versions of old, better data typing.
In HTML DTDs, you don't get much data typing.
It's characters or it's ID refs
and I think that's more or less it.
There are a few other things, Randall, I know.
More interestingly and more fundamentally,
the basic abstract unit in TEI P1 was the tag set,
a combination of HTML specifications that come as a group.
One of the biggest changes we made
moving to the second generation of ODD
was to abandon that idea.
The tags are still bundled together for convenience,
but you don't talk about modules anymore.
You talk about elements and classes of elements
in particular.
This gives you more flexibility because the same element
can be a member of multiple classes,
which is not the case, obviously, with a module.
Consistency was a key desire in the second generation ODD
and the consistent use of XSLT to do everything
made us much more focused.
A work group chaired by my estimable colleague,
Sebastian Rat, reviewed and redefined ODD
for this new environment and there's another link there.
There were a couple of things I just wanted to present
and then I'll shut up, which I rather grandiosely termed
the Durand conundrum and the Afnor opportunity.
And these, I think, are topics that we will come back to
during the course of today and also the workshop
on Saturday that James mentioned.
I've already mentioned this important difference
between ODD1 and ODD2.
That customization in ODD1 was done in terms of modules
or tag sets and in ODD2, it is done at the element
or class level.
ODD2, everything, everything is expressed in CEI XML.
You don't have to learn any other language.
So if you contrast the two tools I've already mentioned,
the pizza chef and Roma, to use the pizza chef,
you have to understand what a tag set is
and what's in each tag set.
You just have to know that and you have to know
how you invoke tag sets and how you combine them,
which is done using a completely different syntax
and a completely different set of mechanisms.
Whereas in Roma, you can use a tool which actually developed
from the pizza chef originally,
a tool which encourages you to explore
the full range of elements in the TEI.
Laurent, I know, and others have used Roma
as a means of teaching what the TEI is,
not simply as a method of generating schemas.
So the Durand conundrum, I don't know if you can see
the picture, Durand is the gentleman on the right,
the gentleman on the left, is he in the room?
David, are you here?
No, he's not, okay.
The gentleman on the left is David Birnbaum,
who is also famous in the TEI, but for other reasons.
The Durand conundrum is very simple.
When we, in ODD1, bits of content model are expressed
in DTD language, not in ODD.
They're just sort of little fragments
that are stuck into the specification.
In ODD2, we decided we didn't want to use DTDs anymore,
we decided to use RelaxNG for a number of other reasons,
but we still generate DTDs, by the way.
So the conundrum which David Durand put to us is,
well, why?
Because in RelaxNG, you can do all the documentation side
of an ODD, remember an ODD is combination
of documentation and specification.
You can do that just as well in pure RelaxNG.
So why not use pure RelaxNG and forget about ODDs?
And that's the Durand conundrum.
I'm not gonna answer it now,
I'm just gonna put it on the table.
I have a presentation I will give on Saturday all about it.
I'm here all week, as we say in English.
The second point I wanted to talk about
is the AFNOR opportunity.
This lovely picture is a view of the lobby at AFNOR,
the French normalization body,
the equivalent of ANSI, I suppose you would say in America,
or DIN, is it in Germany?
Yes.
And this was really the place that ODD generation,
second generation was born, I think,
because it was the first time that we realized
actually ODD was a very powerful tool
that could be used for many other purposes,
not just for specifying how to produce the TEI guidelines.
This was an insight for which I am pleased
to give credit to my colleague Laurent Raunari,
who actually did us the compliment
of taking us very seriously and nagging us
to produce all sorts of improvements as a result.
And I think, are you gonna talk about that Laurent?
Yes, so he will give a much fuller account
of how that panned out in practice.
But just to repeat that this was a major change
in our thinking about ODD.
So I have just a few conclusions to make.
ODD was originally thought of as being necessary
because we needed to express that abstract model
that I started with in some way.
And so I have argued, and been ticked off for arguing,
that ODD is a kind of ontology.
It's not just a database of tags.
It is a statement about what we perceive to be
the things you might want to mark up in a document.
And that's a discussion I think we ought to have
and should have had earlier today.
ODD also provides a very simple vocabulary
for producing regular documentation,
which is closely integrated with the rest of the TEI.
So if you're writing, as I hope you will,
a manual for your markup practice in TEI,
or your thesis or any other document,
you will be writing it in TEI, of course.
And ODD enables you to embed the formal part
of that specification within your document
in an integrated way.
And that's why I think ODD occupies a sweet spot
or an uneasy compromise, depending on your point of view,
between what a documentalist requires
and an information the engineers requires.
So it's a bit like digital humanities, maybe.
That's my conclusion.
Thank you for listening.
.
. .
.
interested in which elements, macros, classes, and modules.
It says which ones you want, which ones you don't want,
and which ones you want to change in some way.
In order to keep yourself TI-conformant,
those changes will be limited to making them more refined,
more specific than they are already.
Confusingly, though not many people use it,
the odd customization can also say, what the heck,
let's import a whole other schema at this point,
MathML being a good example.
If you want to redefine the content model of formula,
for example, to include MathML.
The current odd workflow, which I'm glad to say,
I was quite surprised to discover
we had documented in the TI guidelines, given
the URL down there for those of you who can read and both write
fast enough.
The job of that is to read the customization, which
describes which part of the TI guidelines we want.
Then to read the TI guidelines themselves,
which may be pointed a specific version,
or just implicitly the latest version.
And then it will patch that gigantic copy of the TI
using the specification we gave it,
possibly throw lots of it away, change bits of it.
And that makes a new version of the TI guidelines.
And then that will be converted into the chosen output format,
whether it be documentation or some kind of schema language.
And that's what the processes like Roma do.
However, the intermediate stage, the third bullet there,
what's generated as output from the patching,
can also be used for later reuse or analysis.
And the sanity checker that some of you
have used in the Roma web service is an example of that.
So this leads us to think, a little around
to think earlier on, that we might
like to write a customization which is designed to apply
to an existing customization.
So say if you use TI-TITE, you want your customized version
of TI-TITE.
So you want to follow all the good things
that it does or the documentation it has,
but make some big or small changes to that.
Or you've written a ISO customization of the TI,
and you want to build on that and build in some more features
or narrow it down some more.
So an example there, those of you
who know the odd language, defines an attribute called
whereof in the first customization,
where the data type is simply plain text.
And the second customization wishes
to take over that attribute.
It likes that, the whereof attribute,
but it wants to limit the possible values it
can take to just A or B. So it doesn't want to,
the custom, that should say customization two
on that second thing there, of course.
The second customization doesn't want to reinvent the wheel.
It wants to, if changes are made like documentation
in the first customization, it wants to inherit those.
So how would we go about doing this?
So we've got a customization of a customization.
Blimey.
I don't know what that was.
Quite dramatic, isn't it?
Some kind of awful thunderstorm over Hamburg.
I'll stand back a bit, shall I?
One way to do this, for those of you
who are nerds in the audience, either nerds or geeks,
I'm not quite sure which, is to use the facilities of XInclude
or DTD entities to very carefully pull out
from the existing customization the bits that we want
and build up a new customization using
that into leaving bits pulled out
of the old one with new bits.
I doubt if there are three people in this room
who even know where to start with doing this.
And I don't think you'd finish the job.
The details of what you would pick out would drive you crazy.
The second possibility is to patch the patch.
So customization one is a patch on the TEI.
Let's write a patch on the patch,
generate a new customization, and apply that to the TEI.
The third possibility is to write a customization which
applies to the output of the first customization.
So take the TEI.
So what we do now is we take the TEI source, apply a patch,
convert the results to a schema language.
The first method we could try would
be to take the TEI source, apply a patch to that,
generate a revised version of the TEI guidelines,
apply a second patch to that, and then
carry on generating schema output from that,
or whatever we wanted.
The other method is to take the TEI source,
apply patch two to patch one, then
apply the resulting change to patch one to the TEI source
and generate our output.
I'm going to concentrate on method one here, some
of the implications of it.
The problem with the output from the patching process
that's currently implemented is that this
is where the symmetry comes in.
The output is not quite the same as the input.
It isn't a completely comparable copy of the TEI guidelines.
Firstly, you may have the inclusion of simply gobs
of relaxing schemas like MathML.
And it's not clear where to put those.
They don't fit neatly in the model.
Secondly, the difference is that the output now
starts to define a schema, that it's all wrapped up
in a schema spec element, which defines
the output and some of its properties.
But most critically is to do with something
I'm going to have to take a few minutes to explain to you,
the problem what happens when an element in the first
customization changes an attribute that it's
inherited from a class.
So imagine the bit of code at the bottom, which says,
let's take the element called p from the TEI, which picks up
a couple of attributes called rend from one attribute class
and type from another one.
And it wants to change one of those
and delete one of the others.
It doesn't want a rend attribute.
And it would like to have a different type of a different
way of using type.
If we take that, we can no longer
stop cleanly inheriting from the attribute classes
that these came from.
If we've said that the element p has changed the rend attribute,
then in the intermediate results, when we process that,
we can no longer take p, which says, I am a member of at.global,
the global attribute class.
We can't do that anymore because we've overridden part of it.
And what actually happens in the current output
is that the membership of the attribute class
is replaced with a series of explicit pointers
to members of that class.
So it ignores the fact that it doesn't pick up
all the attributes from the global attribute class.
It specifically picks up the n and XML ID attributes
in the code in front of you and changes the one called rend.
There will be tests on this laser,
so I advise you to pay attention and make notes on your pads.
Now, there is a change waiting to be implemented in the TEI
to change the processing model, which may help us here.
Because what we're doing is something
that some people wish to do right back at base, which
is to say that an element in the TEI, from its very inception,
although it wants to inherit, for instance, a type attribute
from a global attribute class, which
is to change that up front so that it inherits
the same semantics, but may wish to narrow
the scope of it a little bit, so have different possible values
allowed in it.
And if this was possible, it makes
it possible to transfer that forward into an intermediate
output.
The second possibility is that we
can start to refine the odd language to say
that to extend the idea of membership of an attribute
class, this element is a member of class x,
that gives it a certain number of attributes,
to allow for exclusion and inclusion on that.
So in the bit of code in front of you,
we're saying, I'm a member of the typed attribute class,
but I don't wish to include the attribute called subtype.
And this will be a way of carrying forward
to the fact that a customization had deleted subtype
from the p element.
My colleague on the right will now
remind me that p does not have a type attribute,
but that was left as an exercise for the audience to realize.
Customizations, chaining, is ambiguous, of course.
If you have a customization, does
it a customization which customizes a customization?
Does it always narrow the scope, or can they re-expanded?
So if customization A, Gabriel's trying
to call you said, customization A deletes an attribute.
Can customization B restore it?
Is this a requirement for chaining?
Or can you only narrow it down still further?
If I delete an element in customization B,
can the customization of the customization
restore that element?
So it's not as simple as, I mean,
Laurent can come back to this later,
why this is a desirable thing to do to chain customizations
together, but there are certain ground rules
that have to be established first of what can be allowed.
So the conclusions about this, the takeaway message for you,
is that you now realize that the way the odd processing works
is the output of applying a customization
is a new version of the TI to which you could
apply new customization doesn't work precisely.
I would claim, and those of you who have been following this
can argue with me about this, that we
can finagle some of the existing elements to make it possible.
Specifically, the problem area is
to do with inheritance of attributes from attribute
classes and how to record this fact in an ongoing chain
of customizations.
And therefore, it should also be possible to develop
separate tools to start using one customization as a patch
on another customization specification
rather than its output.
So there are two possible ways forward with this.
And I would also worry that there are inherent ambiguities
in the chain.
I think Laurent might come back to this in desiderata
for the case where you're not dealing with a TI,
but where you're building up a new schema from scratch
and wish to customize it.
Thank you.
Who's next?
Thank you.
OK, I'm going to speak about a very small problem as compared
to Sebastian's, which just is about cardinalities
and membership for model classes in ODD.
Well, model classes in TI, of course, there's a must read.
There are actually two, the chapter documentation
elements in the guidelines and using the TI,
if I've got the names right.
I hope so.
Actually, model classes correspond
to indirect specification of the content model of elements.
And therefore, they enable adding or removing elements.
It's because we don't refer directly to element,
but we may remove them, or adding new elements
in the content model of others.
And it probably is his enlargement of a TI framework
that three gems could say.
Elements are therefore usually members of such model classes.
Classes may be members of other classes.
So we've got some kind of inheritance or inclusion
of sets somehow.
And content models of elements are specified by our reference
to these classes.
For example, a class like model HI light
is a member of model I lighted, and HI, the element HI,
is a member of model HI light.
So if you want something that would
be used in the same context as HI,
you could add it to model HI light.
That's the way it works.
So how do we refer to classes, to model classes?
The content model of an element may
be defined through reference to model classes.
And there are actually RNG defines, relaxng.
A simple reference to the class means a choice
among the members of the class, which
means that in your schema, you will be able to use there
any element of the class.
And in fact, very often, this choice
is actually embedded into a zero or more.
That is, you repeat over the elements.
But there are four more possibilities
when referring to model class.
The first is the default. That is,
alternative choice between all the elements of a class.
The second possibility is a sequence.
That is, you want all the members
of a class in the order.
Sequence optional, where you might drop some elements
in the chain.
Repeatable, you may repeat some.
And sequence optional, repeatable,
which means you may omit some and repeat others.
What I just proposed is that instead of just saying
that element A is a member of class C,
we have the possibility to specify
that A is a member of C with minimal cardinality i
and maximum cardinality j.
It just means that when we refer to C,
we will yield among others between i and j occurrences
of A. That's all.
It's a very small modification somehow.
And this, of course, is only for model classes,
not attribute classes Sebastian spoke about just before.
Why would someone want that?
Actually, I wanted that because I needed that in a non-TI
project.
And ODD was a very attractive option
for customizing specifications.
Probably the best tool you could use there.
The only thing I missed was those
cardinalities on membership.
Of course, the fixation of the format
was defined in W3C schemas, which
explains why there were those minimal and maximal
cardinalities.
So as I only lacked that, I decided
to try and get it into ODD.
So a tentative implementation exists.
And actually, it happens to be a very small modification
of the existing style sheets.
I would say it's about 20 lines or so, not more.
I hope it is correct, it seems to be.
But anyway, it doesn't change the way
the system works on normal membership.
So it's not dangerous, I would say.
Now for the perspectives.
So I used it in a non-TI project.
Now the question is whether it could be useful for the TI.
Among the five different ways to refer to other classes,
only two could remain useful.
That is, alternation, meaning choice,
and sequence, meaning all elements in others.
Because for the others, sequence optional
means just minimum cardinality 0 and maximum 1
on all elements, members of a class.
And repeatable means minimum 1 and max unbounded
for all elements and members of a class.
And of course, optional repeatable
means minimum 0 and maximum unbounded.
The main difference is that the granularity
for being optional or not, or repeatable or not,
could be the granularity of each member of a class,
and not the whole class as it is now.
And I think that's all.
Who's next?
Me?
Bye, Dolly.
How much time do you want me to take, James?
All right.
You write the proposal for something like this
quite a bit before you actually do much of the work.
And I had to admit, at the time we started actually doing the work
for this session, I had to back-derive
why I was asked to do this topic.
I think the reason I was asked to do this topic,
I think the reason we wanted to cover this,
is we wanted to cover an issue, a topic, something of interest,
that you can wrap your mind around A, and B, isn't clear.
It isn't obvious whether future, in the future,
odds should handle this issue or not.
It's an open question that we'd like to consider,
whether odds should contain co-occurrence constraints.
In order to intelligently discuss that,
we have to cover what a co-occurrence constraint is,
so that's my little job today.
A co-occurrence constraint is just the case
where one, again, we're writing schemas,
or odds from which we create schemas.
A co-occurrence constraint is a constraint on one node
that depends on the value of another.
Now, typically, the thing we're working on,
the dependent node is an element,
and we're talking about its content model,
is dependent on some other thing, typically an attribute.
So in the TEI language, a very common example
that you can grasp, sink your teeth into,
is if we wanted to require the div element
to have a single head child if its type attribute
had the value editorial or the value op-ed,
to have both a head and an epigraph element
if its type attribute had the value article,
and to have neither a head nor epigraph
if the type attribute was anything else.
This seems like a pretty reasonable constraint
that you might want to have if you were writing a schema
for a newspaper, right?
Do people make sense of that?
Yes?
So that's basically what the constraint that does that
is a co-occurrence constraint.
The first thing to think about,
the first issue to study or to worry about
with a co-occurrence constraint like that is,
is it necessary in your data modeling
to have co-occurrence constraints?
And certainly it's arguable in your data modeling universe
that any co-occurrence constraint represents bad modeling.
There's an argument to be had there
that if you in fact have different content models
desired in different circumstances when you have,
for example, an article versus an op-ed piece,
that maybe you should simply have different elements
because after all they're different things.
And that's a perfectly reasonable argument, I think.
I think, however, there are counterarguments
which are that in the TI universe
it's often desirable to maintain closer adhesion
to the guidelines, vanilla guidelines,
usually because a project starts out that way
and people don't know how to customize it first.
And so now we have legacy data that has these div things
and yet we want to add constraints to make it more consistent
to use automated checking for our processes
and for that adding a co-occurrence constraint
seems like a good idea to me.
But I can imagine both sides of that coin.
In any case, co-occurrence constraints are expressible
in some model schema languages.
In particular, relaxNG,
the language that Sebastian pointed out we use
when we express a nugget of a content model,
it permits co-occurrence constraints to be expressed.
XSD, the XML schema language from the W3C,
the newer version 1.1 does permit some forms
of co-occurrence constraints, but not all.
And Schematron, the open schema language,
is a rule-based language instead of grammar-based language
because it's rule-based.
Obviously it can handle co-occurrence constraints
because you can write those rules
if you have a type attribute of this,
then you should not have that or whatever it might be.
These constraints cannot be expressed in DTDs.
Some might say, who cares?
They cannot be expressed in XSD 1.0.
I hope even more people would say, who cares?
But the important thing for our purposes
is they can't be expressed in a TI-odd language.
And the question we need to ask ourselves is, should they be?
Should ODD 3, as Louis already pointed out, ODD 1 and 2,
should ODD 3 support this capability?
I think we have only 35 minutes left.
Do you have any other speakers, James, that need the podium?
So I think then, in the interest of time,
I'm going to hold off on showing you the code,
but suffice it to say, you can generate a schema
that does the right thing
and presents you with a constraint
that permits you to control a new XML document
that uses div type rock.
That permits you, and I've just added a few...
I'm just using a subset of TI here, I'm not using the whole thing here.
A div element that requires a type, and lo and behold,
it has all of these possible values.
If I make it an article, bingo,
when I try to insert something, it requires a head.
Nothing else is possible.
And if I go to insert something else, bingo,
it requires that byline, nothing else is possible.
And if I go ahead and insert something, it requires a P.
If I do the same thing with a different type of division
with my editorial, shall we say,
I have the head, but when I go to insert the next,
it is not a byline, it's just straight to the P.
That's a co-occurring constraint at work.
I'm going to spare you seeing the code that does that,
but if you want to see it later,
I'd be happy to show that to folks offline.
So if you wanted to have that capability
to constrain the content model of some of your elements
based on their attributes or their parentage
or something of that sort,
you can hack this together in odd if you're very ingenious
and use macros to their fullest extent.
You could, in fact, because a macro is just a chunk of relaxed NG,
do this in odd directly in truth.
I submit that I bet in this room, even,
there are very few people who have done that.
Sebastian, I know, I've done it. Has anyone else done that?
Has anyone gone down that dark and stormy road?
No, good. Don't go there. It's a bad idea.
All the advantages you have of using odd that Lou described for us
are lost if you use this method
because you no longer get to use the TEI elements
that permit you to describe your markup.
You have to use relaxed NG directly,
and you've thrown yourself into the grand conundrum
from the wrong direction, and things are horrible.
You can do these by adding schematron to your odd.
The odd language permits you to add scraps of schematron code
and use schematron to validate your documents,
and that's a wonderful idea.
But the problem with the schematron is that some people
really want to have their constraints at data capture time.
In oxygen terms, they want it in the pop-up box.
They don't want a red underline later on.
They want it right now.
They want current contemporaneous checking.
So the question then is, should we permit this in odd three?
And I'll leave it as a question to handle in the future.
Next speaker, Laurent.
Thank you.
I had my thoughts going on as we were listening to the others.
I was imagining you, owner of a nice Mercedes-Benz,
listening to a seminar from the engineers
explaining how they put together the engine,
and you were like, wow, that's why my car works.
Not mentioning those in there who are just interested in submarines.
And the good news is that I'm going to speak about submarines.
I'm not going to speak about those cars and those kind of things there.
A little bit of background is, well, indeed, as was mentioned already,
we took the idea of odd as a specification language very seriously
within the International Organization for Standards,
and we actually edited several documents
using exactly the TI odd specification platform.
And I think it has been a very interesting testbed for many of us,
not to mention Sebastian himself.
Another parent says, I wish I had a camera in front of his computer
looking at his eyes when he's receiving emails,
asking him why this does not work.
So depending on the difficulty of the question,
you would have an immediate answer.
I will never solve that for you.
So one minute.
Sometimes two hours.
Two hours is always positive because it shows these things.
So it's very nice.
So it's a very nice testbed because it allows to see
how generic this TI specification is for non-TI vocabulary.
And I think there are many people doing that around the world.
So defining their own XML vocabularies for one reason or another
because they don't know about the TI,
because they want to do something very specific.
You mentioned also the ITS experiment by W3C.
And odd, as demonstrated, I think, by my colleagues,
allows to express a lot of constructs
and also to generate this documentation and schema,
this literary computing background that we all need there.
From an administrative point of view,
this has been facilitated because there is a collaboration agreement
between the TI consortium and the ISO central secretariat,
whereby we can basically develop some joint standards,
have this freely available because not all ISO standards are,
and actually working on this TI odd experiment was part of feeding the thing.
Another aspect is that for two years, I think,
Sebastian and a few others worked on a collaboration with the ISO central secretariat
to actually define some customizations and tools
to allow a run trip between TI format and the Microsoft Office OXML format.
Basically, this sounds like a little game at some point,
but this has been an essential aspect for the work I'm going to present.
Most of the results have been integrated in the TI official XSLT deliveries
maintained by Sebastian, hence the spamming he received from me,
not to mention the mobbing, and also Knox Garage for most parts of this, I think.
The ISO use case, I'm referring to ISO technical committee 37,
you need to know your numbers in ISO, called terminology and language resources,
with two subcommittees which have worked on this odd experiment,
the SC3 computer application in terminology, SC4 management of language resources.
The context of using odd for ISO document is also motivated that ISO documents,
for those of you who have managed to see one, are very structured.
So you've got things like your scope, normative references,
term and definitions which are always section one, two, and three,
then you can have your stuff, I mean the technical stuff in the middle,
and then bibliography annexes which can be normative or informative annexes there,
so you need to have a real semantically motivated structure
that will at the end of the day produce your output.
The point is that this output from an ISO point of view is just a plain text expressed in PDF,
so they've got a complex workflow in the background, but basically they don't care,
especially when the ISO standard is about standardizing a new XML vocabulary,
about delivering schemas, DTDs, what have you.
So this is the workflow we basically designed.
We do the whole development of the corresponding standards using TI Odd.
By means of the magic XSLT style sheets from Sebastian,
we generate the doc X that we use to deliver to the member bodies
when there are some ballots to receive comments,
and then we integrate these comments in the TI Odd.
And finally, at the end of the day, when we need to deliver a final format,
we just deliver this Microsoft Word document so that the ISO central secretariat can produce a PDF at the end.
If you look at the diagram more closely, you will notice that hardly anything is automatically done there,
so basically the only automatic stage is XSLT, everything else is done by hand,
in particular this one here, the editing by a node guru.
So you need to take a node guru at random, this one, for instance,
and then you have it edit the ISO document, quite easy.
We actually did that for a variety of standards,
so don't want to bother you too much with them,
but basically two standards related to terminology, which are under revision now, so expressly not,
and these three from ISO TC37SC4 related to multilingual information representation,
multiple syntactic annotation, and temporal annotation there.
So are we happy with this?
Basically, yes, in general.
It's a very powerful editing platform.
It has all you need to actually edit such a structured document as an ISO document.
You don't have fancy features which may occur any time.
I mean, you know in advance there is these so-called ISO guidelines, 30 pages,
you just need to implement that and that's all.
All the TI facilities, bibliography, cross-references,
the fact that of course you can have in odd element specification
with inline description within your plain text,
allows you to have a very efficient editorial workflow there,
and a very coherent output as a consequence
because every markup is semantically motivated.
So you don't have to bother about putting something in italics,
in bold, in something nice, you don't care.
There's a nice statute to produce that for you, of course.
And finally, this perfect match between specification and documentation
that odd gives you is essential to ensure that each time you generate the schema,
it is perfectly coherent with the corresponding documentation
you put in your ISO standard.
Are we happy with this?
I think you've understood that all those people there are geeks.
At least when they speak in such a panel, they've got other qualities,
they do other things in their life,
but basically when they speak about odd, they are definitely geeks,
and most of you would not want to go in there,
which is a real problem when you want to apply such a workflow
to a standardization committee where you've got,
my best example, Paribund.
Some of you may know him as a real specialist in semantics,
but he knows nothing about XML,
so imagine putting him in the situation of editing odd documents.
It's painful.
The limited support, so we've got a strong group of three persons
mentioned there providing online support each time you've got a question,
so basically Seb, Seb and Seb.
And this is also an issue for all the nice technical evolutions we've heard
from Bertrand, from Sid, what have you,
that we need to take into account that
if we make odd more complex rather than more terse or coherent,
we'll have to make sure that we produce the corresponding support in the background.
The other point is that we lost the notion of round trip.
This is where I said very few things are automatic there.
So as soon as you produce a doc document,
you should not let anyone edit this Microsoft doc document
because you cannot reinsert the corresponding changes within the TI,
and this is something we would like to have for such a workflow.
And I think seeing things on the TI list and notings there,
that we would not be the only one to require such a feature somewhere.
Guess what is missing there is basically that I'm not criticizing odd.
At this stage, for a one-shot activity of producing a standard,
odd is just perfect.
You don't want to create a not three, not four, not five for this.
Except if we want to go a little bit further,
like I'm going to explain now.
So we're in the situation now for one specific standard, TBX,
to actually duplicate what we already have in the TI.
We want to have TBX as a generic XML vocabulary
for expressing multilingual terminologies,
but from this being able to create subsets.
So very simple bilingual terminologies
to express bilingual glossaries, for instance,
or more complex customizations to make translators,
workbench, interoperable with one another,
or similar activities you can imagine if you know a little bit about terminology.
Those models can be very complex or very simple
and still being kept interoperable.
So we want to create a real family of document models
and using odd in these respects.
From what I heard, I've got my answer to my question.
From what I heard from Sebastian, this is not yet possible.
And why this is not yet possible?
Basically because patch, patch, patch, who spoke?
Patch, patch, you said.
There was always on the left-hand side TI.
So as soon as you've got such a diagram,
you need to start with the TI vocabulary.
When I did a not file to define another vocabulary,
I've got to keep in mind that I've unplugged the TI architecture
in the background to create something else.
So the basic idea would be for the TI in the next step
to actually consider that the TI is just one foreign application
as another based on the TI vocabulary
and not the specific one, the basic one.
The point is that we don't want to...
Oh, my goodness.
To throw the baby with a bath.
Because there are many things we want to take up from the TI
when we actually define new vocabularies.
It would be stupid to reinvent Beebel's truck
in terminology vocabulary.
It would be stupid to define the header
because we've got many things there already.
Cross-references, grammatical descriptions,
many things which could go into a terminology object.
In particular, if we've got in mind the idea
that we would need something we lost in the middle of the reverse
at some time, a terminology chapter
or terminology module in the TI framework.
So implications for the future of ODD,
I think at the last slide.
Perfect.
I would argue for a very pragmatic strategy
for the evolution of ODD.
So we should not, you know, close ourself in a room for two days
and think of all the fancy features we would like to have
but really identify the features which are needed to provide
step-by-step a more coherent framework.
We need to make sure that tools are implemented.
We need to anticipate, like I said, the needed support
each time we introduce a new feature.
But we need to be clever.
We need to be visionary.
We need to have a clear understanding of the underlying theory,
inheritance mechanisms.
What does it mean to do semantic or synthetic checking
as a result of our own specification?
It's not part of this talk,
but it's part of our hidden agenda as a whole.
The final point which is more a question for the current Council Chair
or members is, well, do we need to go for a TI P6
in order to do a new ODD?
I think not.
I think it's not a good reason to go further.
The main aspect is really to manage transitions.
So we need to be good enough to be able to compensate
for the actual changes we introduce in the framework.
So as a conclusion, the last one,
you're not required to open your car to look at the engine
every day you start your own car.
But it's very important that you've got some idea
that the thing works not by magic,
but really because all the customization facilities you have,
it's because a lot of people are thinking about it,
a lot of people are implementing about it,
but it's also required from you that you come and say,
we should have this feature.
I'm not even sure it is feasible, manageable,
but I remember discussing with those people there,
I want to be able to tune my element like Sid said
in order to have only this element in the context and this element.
If it is an acceptable use case for you,
I mean, if it is a mandatory use case for you,
you need to tell James, basically.
Thank you.
APPLAUSE
Right, we're going to start with some questions,
and I have a microphone,
and so I'm going to hop down and run around
and get lots of exercise,
which I'm told is a good thing.
Does anybody have any questions for our panel to start with?
Or actually, did any of the panel have questions for each other?
Maybe we can start there.
I was going to just preempt one question and answer it myself.
Just to preempt the question and answer it,
yes, the penguin on the tie is Tux, the lunix penguin.
Thanks, Sid.
I had a question about the co-occurrence of constraints,
but it's sort of partly for Sid and partly for Laurent,
which is, would one of the major useful advantages of this
be back at the TI source
and doing things like constraining
what is allowed inside a paragraph
when that paragraph is in the header?
Yes.
Can I give a very precise use case?
When you've got a structured documentation
like a NISO document, but take that metaphorically,
you have situations where a section is typed terms and definition,
and the only thing you want there is one paragraph
and then a series of terminological entries.
If you've got a scope, you just want to have one div
with a series of paragraphs.
You want to have it very constrained.
If we want, again, to take the TI specification idea very seriously
and offer professional tools to some external communities,
most of the people here don't care
because they've got all their life until they retire to learn the TI.
Some people in the industry would like to have something
which is applicable in one or two weeks to their people,
so we would probably want to go in this direction.
I was joking concerning the...
I wanted to comment on what Laurent said that relates to that,
about authoring and people not having the rest of their lives to learn TI.
One of the intentions of the project that he mentioned with ISO and TI
was to make round-tripping possible, and indeed it was possible.
What was not covered was the very specific case of odd
because only one percent of ISO specifications
are defining an XML language,
so that wasn't covered in the specification.
If your desire is to write an ISO standard about hard colon coke,
then it's perfectly possible to write it in Word
and have that translated properly to TI and back again.
Ad nauseam. On a good day.
On a very good day.
Thanks to all the panelists.
It's very interesting to hear what you're thinking about.
I'd like to speak also to the co-occurrence constraints
because I think that's actually a really important issue,
and it's important to get it right.
I don't have any solutions for you,
but I think there are a couple things you want to think about.
Number one, Sid, you left out the biggest reason why people
want to layer the validation instead of modify the schema itself,
and that is that they want to interchange the documents transparently.
They don't want to have to provide an extended tag set to their partners
and then have to transform it every time in and out,
especially within the TI community where interchange
and interoperability is a big stress.
It's one of those things where every time you recommend
extension, you need to recognize that you're also recommending
that we compromise on some of our goals.
So that's an argument for handling the co-occurrence constraints
that you're suggesting in a layered way.
Now, with respect to the question about schematron versus relaxNG,
I think there's really actually a very interesting argument
against doing it in your relaxNG.
From the user's point of view, things can be very disturbing
if two different divs behave differently because of an attribute flag
or maybe two attribute flags or maybe an attribute that has one value here
and then another value there works the same way,
but then a third one works differently.
There's an issue in terms of transparency.
Now, of course, it's really nice, as you showed,
to be able to handle it in the editor so that when you're creating content,
it prompts you directly so that you don't have what I call the hurt lines.
When oxygen says, I hurt here, I hurt here with a little squiggly red line.
But on the other hand, the advantage of doing it in a layered way
with schematron is you can write your error messages very, very specifically.
You can say, you know, it's this kind of a div which requires a byline.
And you can't do that if you're doing it at the level of the schema.
So that's not really to argue for one or the other so much as to suggest
that there are a range of different tradeoffs here at different levels of the system
for different sorts of different users and so forth.
And there's a big difference between creating a document from scratch
versus validating a document that maybe somebody has given you
and your schema is tighter than the one it was developed to
and suddenly it's throwing errors and you have to diagnose, debug those,
various different sort of scenarios like that.
So, you know, in the kinds of systems I worked with,
we found that a layered system, you know, a discretely layered system
with the schematron held separately is actually a very good way to go.
And in addition, it gives you other architectural advantages.
You can switch out the schematron much more easily
and you can have different schematrons or different workflow stages
or different document subtypes and, you know, gives you other kinds of flexibility.
So, you know, those are all things that I think you might want to think about.
Does anyone on the panel want to comment on that?
Thank you.
One of the things I was thinking back to sort of what Sebastian said,
but also Lou, you both talked about odd processors in some ways.
If we did define a new odd three, what would the processor for that do
that the current processors don't do?
Where should processing of odd go in the future, I guess?
It's a rather simple point, but there are two fundamental problems
with the current odd processing, or several fundamental problems.
One is there's no test suite for anybody.
If any of the audience are thinking, hey, I could go and write an odd processor.
How do I know I've got it right?
There's no test suite for you.
And secondly, it's considerably under-defined.
If you look through the definitions of everything in the TI guidelines,
you can easily think of, well, what happens if I do this and that?
Is that legal?
There isn't a one-to-one match between the specification and implementation
because there's ambiguity in the specification.
So there's a simple example of that.
In a customization, if you say, I've got to change this element,
I'll change the description slightly.
Oh, I've got another change.
I'll narrow down the values for one of the attributes.
If you put these two changes within a specification, is that legal or not?
It's not clear.
So there's a whole – it's not a sophisticated answer to James's question,
but it's a problem for the TI that we don't have a robust system
with which we can easily write a replacement for.
I think of the odd as a space of tremendous underutilized possibility.
And I think part of the reason for this is because at the moment,
the things you can do with odd in a sort of practical sense,
the kinds of processing that are available for odds,
all have to do with producing a schema which you'll then use to encode your texts.
And so there's a certain kind of pragmatism for a lot of people in developing the odd
where, you know, once you have a schema that's working, you feel like your job is done.
And I find myself wondering, particularly as I start to think more about data modeling
in a pedagogical context, whether there are ways to think about processing the odd
that aren't quite so pragmatic, that have more to do with understanding
what the odd can tell us about how we model our data that would then kind of put pressure
in a benign way on the odd developers among us, the sort of novice odd developers,
to be more aware of the role that the odd is playing in shaping the data
and to embark on that process in a less purely pragmatic spirit
and in a more spirit of documentation sharing, actively thinking about data modeling,
and so forth, and whether that would have a kind of virtuous effect on the role
that the odd plays in interchange, in communication, in documentation, and all the rest of it.
Can I respond to that? Is this all?
Yes.
Yes. That, I think, is one of the least understood but most important aspects of odd.
It isn't just a way of producing a schema.
It's a way of documenting your view of your encoding.
One of the things that novice users of the TEI are always saying is,
oh, but I didn't know that tag was meant to be used like this,
or, oh, I just got this text, and they used this tag in a particular way.
I wasn't expecting that.
If every project that used the TEI produced an odd that said,
we've used these elements, and so here's our schema,
and we've used them in this particular way, and this is how we intended it to work,
and so on, life would be a lot easier.
And I think I would also, picking up James's question,
one of the very simple ways in which we might do that is to think a bit more
about the kinds of output that a schema, the specification part of an odd,
might produce other than a schema.
You know, something trivial like a nice graphic, do that again, Julia,
one of those would be really useful, and not difficult, you know,
because it's, you know, we do it in SVG, it's another XML transformation,
Sebastian could whip it up overnight. In fact, he probably will.
So, yes, I think that was a really good intervention. Thank you.
Can I add something else to that, which I've long thought of, well, not long,
a few years, thought of putting in there, which is, this is a bit contentious,
but the default rendering rules.
So, you know, when I say there are three different type values for high,
you know, I call them bold italic and something else,
to embed in there the rendering of them,
I realize that's a bit of a can of worms to get into,
but I think it's something worth considering to not just, you know,
maybe that's an unfortunate example, because there are other ways of doing it,
but there are places where that could go back to the base TEI as well.
So, I'm interested, for instance, as an output processor,
of talking about whether things are inline or block elements,
you know, thinking of traditional page types, I think.
So, I'd like to record decisions like that.
I'm going to respond to Julia's question by jumping back to James's
and saying, one of the differences I would hope for for a future-odd processor
is to treat customization the same as it treats building the guidelines,
so that one of the outputs of either customization or build,
because they're the same process now, is an entire P5,
with its languages chosen with generic identifiers identified
in an abstract way by their ident value rather than by name,
so that you've built a version of the guidelines that matches your project,
an entire set of the guidelines that's matched your project,
and that set of the guidelines should also permit, I think,
the very kinds of documentation, expanded documentation
that Julia and Lou have been talking about,
as well as perhaps the graphic visualizations
that we are now going to insist that Sebastian produce.
But, of course, you'd also do this not necessarily starting from the TEI.
Right, exactly.
So, the base might well be an ISO or, in my case,
it was the itsy-bitsy-teeny-weeny simple-hyper-dex-dd that I wrote an odd.
I had a question going back to something Wendell said about
using different schemas at different points in your workflow,
and that's something I've always tried to promote,
that one might use a different schema when you're doing your mass
ingest of text as opposed to when your encoders are marking something up
might be more tightly constrained,
and then when you're publishing it and you just want to check things
before publishing it, you might be having different checks.
Should we be having different odds for all of those stages in the workflow,
or should we be having one odd that allows us to generate
multiple differing schemas?
We should have patches on patches.
No, I mean, this is the notion of family of formats.
If we don't have this facility, it's not just an intellectual game,
but another expression in French, but I will not use it.
It's basically handling, if you've got a complex workflow,
the coherence to have a global schema,
global odd specification corresponding to all the elements you want
to see ever in your workflow,
and just during the editorial phase provide the necessary reduction
and during some specific annotation phases have a specific customization
for that, and so on and so forth, and maybe for publication,
another one which is just enough to say,
this is the way my corpus will behave, whatever you think.
Can I just say, James, there is a facility that not many people use,
which is the ability of customization and odd to define multiple output schemas.
So as schemas, there can be multiple schema specs,
and there are ready facilities to refer to groups of customizations.
So if you have a customization which changes the meaning of formula
or a table or something, you can include that in different schemas.
So it doesn't go all the way, but it involves some of it.
So for instance, the ISO thing I did for ISO has got three versions,
a bare bones one, a full one, and an extended one,
all built from the same set of source.
This is the issue, I think.
I'm turning to sit with the TI libraries specifications.
You've got one odd per level, but none is directly dependent from the odd.
You don't have odd dependencies among the various levels.
You did by hand, basically, the various...
By inclusion, yes.
By inclusion, which is exactly, I mean,
the kind of use cases where the library would benefit from such an architecture.
Yes, so in that case, you're not chaining them together,
like Sebastian was saying.
Correct.
Not chained, but using an inclusion mechanism to include the common bits.
That's geeky.
Yes.
Yeah, don't do that.
Wait till we solve the chaining them together, I would say.
Are there any other questions from the audience?
Several people on the panel mentioned that, you know,
you have to be real geeks to do odd.
Oh, I never said that.
Sebastian did.
Well, I can't remember whether it was geeks or nerds or something like that.
But of course, you know, I mean, the tools that are available
make it fairly easy to do this, you know, to do basic customizations.
But I guess my question for the panel as a whole would be,
what can we do to make it easier,
either easier for people to become that kind of geek
that can hand edit their own odds,
or what can we do just to make it generally easier
so you don't need that goober?
You don't need to, you know, email Sebastian and say,
this bit doesn't work.
I mean, I repeat the answer I made earlier,
that there isn't a titan of specification or implementation
to make it attractive.
I would say that if this is a chicken and egg thing,
people won't write nice editors.
So Roma is a halfway odd editor.
Not sufficient in this day and age.
Somebody won't write a better one until they trust the underlying system.
But that would possibly be my view.
The alternative view is that if you don't build a nice editor,
nobody will ever improve the underlying one.
Just comment on that.
If that argument was true, there would be no such thing as a web browser,
because the HTML specification was hardly very precise when it began.
I would answer on the opposite side of the spectrum.
It's a matter of culture.
You mentioned, Lou, that I'm using sometimes Roma to teach TI.
The point is that when you teach TI,
even to people who are not technical people,
you need to introduce the notion of customization at a very early stage,
so that it's part of the natural process of someone in literary studies
and linguistics and what have you,
to understand that using the TI is not taking the whole thing,
it's really having the full benefits of those mechanisms
that will restrict the TI framework for your own application.
So we need to exchange this culture.
You don't need to know how it works in the engine,
but you need to know,
and I think we all know that sometimes we need to change oil
or the winter hyphen.
There are a few things that we need to know to make the engine work.
And this is part of the teaching activities.
This is a responsibility for, I see a technical person at random,
for technical persons working with non-technical persons
to explain those mechanisms and so on.
Yeah.
One way, from looking at it from a slightly different perspective,
one way of making odd more,
or making people more likely to use odd,
is to make odd visual.
And this is something that I've been working on,
and I'm a bit embarrassed to say that I was going to have something ready
for this year and consequently for this panel,
but actually I got distracted into looking at various visual methods.
Anyway, so the little message that I, well, over time,
that I have a few seconds to provide,
is that it seems to me that it might be worth it
to kind of tie bits of odd, if you think of the odd source,
so bits of the odd source elements,
to something like UML classes
or UML elements of a UML representation,
and then compose the source out of the UML that you assemble,
and then work on the basis of that source,
because one thing in XML modeling is that you have UML,
for example, UML on one side,
and various schema languages down there in the modeling hierarchy.
And the most common of them is XML schema.
And here we work on the basis of relaxing,
and one of the questions is,
why do people not go for modeling,
for providing concrete serializations of UML in relaxing?
I don't know, it may be a matter of the culture,
it may be that XML schema seems to provide better facilities,
but if we make ODD the serialization of UML models,
perhaps we are catching both birds, in a way.
That is, we have the freedom of going from the ODD node,
from the ODD level, into the schema language of your preference.
We're over time, so we've got to stop.
But if you've enjoyed this, then remember,
Saturday in the West Wing Room 222,
there's a meeting on the Theory of Odd.
Thank you to our whole panel.