Re: Progress on HTML 3 (acrobat, applets)

Michal Young said:

> [I said]:
> >Version 1.0 is available for SunOS 4.1.3 - it does not do searching, it has
> >printing problems, and is not being further developed.
>
> It does run under Solaris (I use it regularly).  I cannot vouch for this
> other information which comes from the Adobe www page, under system
> requirements for Acrobat:
> 
>       SunOS(TM) version 4.1.3 or later, Solaris(R) 2.3 or 2.4
>       HP-UX 9.0.3 or later
> 
> >Cite them, please. I believe they do not exist.
>
> See above.  The only one I have personally seen with my own eyes is Acrobat
> reader 1 for SunOS and Solaris;

Thanks.  I have verified that this is correct:  I was wrong in my
initial posting.  Adobe has supported a 2.1 Acrobat reader on Solaris,
SunOS and HP-UX since Friday last week.

<petulant>
 Typical! I bug Adobe for months to release an alpha HP-UX reader, even 
 offer to sign a non disclosure, then I go out of the country a couple 
 of days and they release a full version behind my back! ;-)
</petulant>

> if you say the Adobe page is fibbing about
> having an HP-UX version, I'll have to take your word for it.

No, I was just going on information that was a week old; you are correct
and I was wrong.
 
> But whether or not acrobat is or becomes an available solution, I think we
> agree that it is not the preferred solution for encapsulating mathematics.

Certainly not if that means the whole document has to be in PDF just
because it has a couple greek letters in it.  Probably not as an inline
either, having read your later comments.

> >Phill Hallam-Baker of W3C spoke to me last year about math support in HTML 3
> >and the intention at that time was *not* to replicate TeX/LaTeX, which merely
> >describe pictures of equations. He wanted to describe the equation; so there
> >was enough info there to drop in intio say a symbolic algebra package or a
> >graphing program.

> This sounds right.
> 
> > That does not seem to have happened.

> Too bad ... and I hope it isn't too late.

Sure its not too late.  The HTML 3.0 draft has expired.  Bits of it
(such as tables) are being sawn off to make Internet Drafts.
There are currently IDs for tables, Internationalisation, 
file upload from forms, and client side imagemaps. Not all of these 
came from the HTML 3.0 draft, which has no a priori special status.

Periodically there will be a Glue RFC issued to update the HTML
specification (HTML 2.0 is RFC 1866) which will pull together the 
various IDs that have implementation track record and have been 
found through experiment to be worth adding to the standard. 

Currently, I believe I am correct in saying the HTML-WG does not have an
ID or any sort of work item for math in HTML.  There is work being done
on updating the HTML 3.0 draft FIG element to allow embedding of
arbitrary media, which also harmoniseds the HotJava applet tag.  It was
this work that prompted me to suggest embedded math as an alternative to
HTML 3.0 draft math, which I interpreted Malcolm to be saying was too
feeble to be worth serious consideration.  

If people in the community feel they they have a better solution for 
creating HTML documents that contain equations, by whatever method, 
then there is still time for an ID to be written describing this 
alternative method. And if it proved to be a better idea, then it would be
incorporated into a later revision of HTML.

> >OK, so I hear you saying that it must be possible to link into equations
> >using fragment identifiers on URLs, and link out of equations (into HTML
> >documents, and other things).

> Yes.  I wouldn't insist that fragment URL's be the linking syntax, but I do
> not want equations to be blobs ("binary large objects", i.e., opaque stuff
> whose internal structure is not accessible to browsers and other web
> tools.)

But you do want to link into the internal structure of an equation, thus
some sort of fragment identifier is required. Fragment identifiers are not 
part of a URL, according to RFC 1738.

> >If you could do that using a media type other than HTML, but which could be
> >embedded inline into an HTML document, would that satisfy your requirements?

> Another media type *might* be ok, but the question is how its structure is
> made comprehensible to web tools.

No, then. You also have searching and indexing requirements.

>  Embedding it inline isn't enough --
> again, that could be addressed by the "blob" solution.  If inline embedding
> is the approach to be taken, then the issue of internal structure is the
> same as for other embedded objects: Are they only leaves of the document,
> opaque to tools that understand html, or do they have structure that html
> processing tools can access and manipulate?

> I'll try to make this a little more concrete with an example.  There are
> tools that read a set of web pages and produce indexes. Those tools cannot
> know specifics of every possible plug-in or applet. Can they include
> portions (terms, variables, expressions) of equations in indexes?

Fine, though that seems to be mixing up two issues:

a) you want some indexing tools to understand equation structure
b) you want html processing tools to be those indexing tools

Equations are not currently part of HTML, thus unless someone has
implemented an experimental structured indexing engine for HTML 3.0
draft documents we can say that no current HTML indexing tools
understand equations.

So, indexing tools would need to have support for equations added.
Whether that is done by extending native HTML and extending the search
engine to cope with that new syntax, or whether it is done by embedding
a new media type and extending the search engine to cope with that new 
media type and it's syntax is in many ways a separate issue.


> One could design a plug-in solution that permits this, but it would require
> careful consideration of an architecture in which every plug-in is
> responsible not only for producing displays of embedded objects, but also
> for providing structural information

OK, fine, in other words the plud-in or applet has to communicate with 
the browser, not just to get some display real-estate but also to satisfy
internal cross references.

I will forward this requirement to those folk on HTML-WG who are dealing
with the EMBED proposal.  It seems a fairly generic requirewment so they
should be please I guess ;-)

> --- internal link names at a minimum,
> preferably hierarchical structure as well (e.g., I want an index of a
> document containing program fragments to include elements from those
> program fragments).

Um, is this the plug-in still or are we talking about a server side
indexing tool now?
 
> Maybe this is being addressed already in the design of plug-in protocols. I
> hope so, but I'm skeptical because embedded elements seem typically to be
> thought of only as unstructured leaves of a document tree. 

If you mean embeded objects as in the IMG tag, I agree 100%.  If you
mean embeded objects with the FIF or EMBED tags then I would say it is
too early yet to form that judgement. If you want embedded objects to have
accessible, searchable structure then put that forward as a requirement.
Anyone can comment on any HTMl-WG draft; the embed work is so new that 
there is not even an ID yet - so it is that much more amenable to change.


Folks - not meaning anyone in particular, this is a generic comment - do
not loose heart or consider the HTML standardisation process to be a
closed shop that you cannot influence or affect in any way.  You can.
Also do not assume that the current big players in the browser market
are the only ones calling the shots.

I hear many folks in the academic community say that they want to do 
math in HTML, one way or the other. So, let's do it.

-- 
Chris Lilley, Technical Author and JISC representative to W3C 
+-------------------------------------------------------------------+
|       Manchester and North HPC Training & Education Centre        |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: Chris.Lilley@mcc.ac.uk |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
| Timezone: UTC        URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | 
+-------------------------------------------------------------------+

Received on Thursday, 9 November 1995 13:30:53 UTC