Strong Typing in SGML and XML

Alan Spencer chaotic at
Wed May 7 11:41:54 BST 1997

In message <6259 at>Peter writes:

> > To allow maximum flexibility and precision for numeric values, we should be
> > able to specify the form (roman/arabic) and a base. The rounding allows us
> > to constrain the significant digits to some factor of the base. A rounding
> > type would be needed for the greatest flexibility (round/ceiling/floor).
> > 
> > Temporal values can specify either an instant of time or an extent of time.
> > They should also be able to be rounded. When an instant is rounded, the
> > significant digits are to the left; when an extent is rounded, the
> > significant digits are to the right. To signify that an instant is precise
> > to the nearest five years, it would be rounded to 0005/00/00 00:00:00. To
> > signify that an extent is precise to the nearest tenth of a second, it
> > would be rounded by 0000/00/00 00:00:00.1 .
> I assume this must be a frequently solved problem and we shouldn't try to 
> reinvent it.  I someone more knowledgeable than me says - 'use the FOO
> approach' I'll probably buy it if it's stable and implementable.
> [...]
> > 
> >                                            -- up to 20 repetitions of
> There has been a regular and repeated cry for regular expressions.  If 
> someone comes up with one that is available, I'll buy it.  Surely one of the
> very many readers of this list is authoritative about this?

I'm certainly not an authority on regular expressions, but I have been using
the one in perl for many years now and I find it meets all of my requirements.
It can be a bit messy (but aren't all regular experssions!). I'm
sure most of you know how it works, it is quite like the one outlined above.
It may be too complicated for what is necessary, as I'm sure that is a goal
here, to make things as simple as possible and only as complicated as necessary.

The ideas may need to be changed a bit, but the underlying structure is
definitely there, the 'telephone number' example would be similar to that

What is the plan as regards things not matching the constraints, I presume
it is just a strict error, ie. not a valid XML document. Is there any plans
to give a flexability to the rules, as to make corrupted data, for example,
parseable, as is the case with HTML, most browsers are fairly smart when
it comes to 'guessing'. This *is* a bad thing most of the time in HTML, as
it promotes guess-work on the part of the inexperienced author. I have 
experienced this with co-workers using WYSIWYG editors - 'It looks good
on my computer, what's wrong with yours'. So I suggest this very lightly,
I don't want to promote that.

As regards to the strong typing, could there be generic types which a particular
application/Style would define, or even go undefined throughout. There
are applications which work with arbitrary percision calcuations (like calc
on UNIX), this would need a generic *real* type. For example,
I have an interest in Mathematical formatting, simillar to that done by LaTeX,
but with a more structured approach, ie. these documents could be parsed as
formatte text or as real mathematical equations/functions/...
For example, in TeX the code: "x^{ijk}_{lmn}" will produce:

This doesn't define what this *means*, just what it looks like, it could be
powers/indecies.... So if I was to try to define a generic variable *x* and
add the functionality to it, it would make sense.
If I am actually making sense, myself, any input on this would be helpfull.
As far as I see it, if there were generic types, or maybe *a* generic type,
people could extend the basic types using styles to add the necessary
functionality to these types.

I'm not if I am starting to tend towards a type of programming language, but
what the hell.

Alan Spencer.
> This is a very critical discussion for me, and I expect for others and shows
> some of the new things that XML will be used for.
> 	P.

xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list