I'm not sure what your exact requirements are with respect to the
HTML/MHEG conversion, but am assuming that it relates to issues being
raised by DVB, and ATSC about an HTML solution for their STU
specification (about which I know very little).
Depending on what you intend to do, converting between these two
technologies will result in some loss of functionality at best. So the
real question is why would anyone want to do this; but that is not the
issue I assume you want to address.
First off when I refer to MHEG, I refer specifically to MHEG-5.
What is MHEG-5? It is a standard that describes a specification for the
interchange and display of Multimedia Hypermedia (MH) objects. The spec
describe a set of classes (some 31, I think off the top of my head) plus
other entities, that supports interactive MH applications including
Broadcast digital TV etc. The standard contains specific conformance
requirements that are Application Domain (AD) centric.
Like any OO system, objects of the MHEG classes describe data and
methods: attributes and actions; has typical OO features, such as
hierarchical relationships, inheritance, blah, blah blah. Effectively an
MHEG system (an MHEG engine and its associated applications) describes
all of the features necessary to retrieve, interchange, and display MH
content, including images: moving and still, audio, graphics, text and
hypertext, and real-time streams - <bold><italic>but does not describe
the content</italic></bold> itself.
In addition to specifying, buttons, sliders, list groups and other
features necessary for proper MH display and interaction, it also
specifies the expected behaviour of the actions that can be applied to
these objects (given their state). Effectively, an MHEG engine is an
event driven device (but does not necessarily have to be one), that a MH
application uses to retrieve, navigate within, interchange, interact, and
present to the final "user" application.
For example, an MHEG engine implemented in an STU, or hand held device
retrieves MHEG objects from a remote server, decodes, and interprets the
objects for an application that presents the objects to the viewer.
In a Digital terrestrial TV application, the MHEG engine would
effectively provide the buttons on the screen, the links to the text
about the Objects being viewed (e.g., statistics=cs about a player or
team), and all the actions to start an stop the display as well as menus
etc.
In other applications if the content is JPEG it shoots it to a JPEG
decoder; MPEG to an MPEG decoder. If its HTML text it shoots it to an
HTML interpreter, a browser perhaps. If the text or audio, or graphics
needs to be synchronised with a video stream MHEG has the action sets
that can support this.
So, there's MHEG in a Nutshell. If I have mislead you in any way about
the description or functionality of MHEG-5, I'm sure other members of the
MUG (to which this is CCed)will jump on it like a dog on a bone and put
it right for us.
Now what is HTML? Here I am not an expert, but I'll try by best shot.
HTML is a DTD of SGML, or a subset of the extensive document markup
language. It began life as GML, a proprietary IBM product, then given
over to ISO. HTML began life as a very restrictive markup language, but
has been adding more and more functionality into the DTD.
It is not OO oriented (yet) hence has no real concept of methods or
actions, does not describe the behaviour of its "components", and
accordingly, has very little capability to describe semantics. In its
present form I am not sure it can handle events and actions, streams,
synchronisation, complex scene description and other features of an MH
presentation, but I understand that these are some of the features that
XML and perhaps SMIL will attempts to describe in an HTML like way. I
believe the attempt to add MH functionality to SGML resulted in HyTime,
which was again limited by its "Mark-up Language" features, but don't
quote me on that.
Now what do you mean by converting HTML to MHEG. If it's simply a matter
of handling HTML documents in the MHEG environment that is no problem. If
you mean mapping HTML features into an MHEG application that is more
complex, but I'm sure it can be done, just as sure as it could also be
mapped into COBOL. But is it worth it? Perhaps. I'm sure complex features
of HTML e.g., Frames and Tables require some thinking about, but it would
seem that list, and group objects combined in a scene could handle it.
All of this needs further discussion, as I'm sure all of us realise there
are many good technologies out "there" waiting to be exploited. MHEGers
need to reconsider the relationship between HTML and MHEG. This is
especially so since more and more people are concerned about defining the
convergence of Broadcast TV, Telecoms, Interactive TV, and Web
technologies.
I have not discussed the programming aspects of either MHEG or HTML,
which can be handled by "outside" calls to program objects or script
languages like JAVA.
Hope his helps. Let's continue the discussion, as I think it can become
the basis for study within WG 12. As convenor of MHEG, I would very much
like to put this topic on the Agenda of our next meeting(s), as I'm sure
questions along these lines will continue to emerge.
BR
Tom
At 11:19 20/08/98 +0100, Sima Arman wrote:
>
>Hi all,
>
>I need to find information about converting HTML to MHEG. I need to
know
>what the key issues are in designing web pages which needs to be
>converted to MHEG. I believe there are limitations such as frames,
>scroll bars. I have not managed to gather sufficient information, so i
>would be grateful if someone could tell me where to get some.
>
>Sima Arman
>
Dr. Thomas J Casey Research Fellow, Oxford Brookes Un.
59 Florin Crt tel: +44 (0)171 490 5322
email: tcasey@tcasey.demon.co.uk
Latitude Longitude