🚀 go-pugleaf

In article <appelt.720455954@hera> appelt@hera.gmd.de (Wolfgang Appelt) writes:
>- There exists a close liaison to the MHEG group in SC 29. In fact,
>  WG 3 members participate in MHEG meetings, and vice versa.
>
>email: appelt@gmd.de
>kKeywords: video ODA multimedia

This reminds of of a question.  What's the relationship between MHEG
and HyTime?  And between ODA and SGML?

In article <appelt.720455954@hera> appelt@hera.gmd.de (Wolfgang Appelt) writes:
>  have to be added. (Group 4 fax is already included in ODA).

>- WG 3 is currently working very actively on hypermedia extensions of
>  the ODA standard where one of these extensions is the introduction
>  of the concept of time, e.g., each layout object receives a position
>  and duration on the time axis in addition to the current two-dimensional
>  spatial coordinates.

>- The usage of X.400 for transmitting ODA documents is already
>  addressed in Part 1 of the ODA standard.

Thanks for your very informative reply, but I am still puzzled by the
lack of convergence between these standards. 
And why include time in ODA when time is part of MHEG? Can't you converge  
  a) MHEG  
  b) ODA
  c) Group 4 fax, i.e. T.73 TIF.0 and TIF.1
  d) IPMS message bodies
By all means let's have 'profiles' to extract subsets of a common standard
for use in fax, e-mail, etc. Surely this is better than having four 
incompatible ways to produce multipart documents, each of which has unique
capabilities. It makes it hard to reason formally about things, or to write
simple rules for program behaviour. E.g. what (to the user) is the 
difference between a IPMS message containing two TIF.0 body parts each with
a single image, one TIF.0 body part with two images, one ODA body part with
two images, etc.? If a sending user says "send Fred these two pictures"
which form should be used? Should the recipient MUA present them differently?

What form does the collaboration between ODA and MHEG take? Is it simply 
a case of duplicating functions? Or is MHEG going to become an application
of (the new) ODA, in the way that HyTime is an application of SGML? (Or,
perhaps more accurately, in the way that SMDL is an application of HyTime.)

p.s. I saw a comment recently to the effect that participation in standards
efforts requires two out of: time, money and experience. I have none of them.
So please excuse my naive posting!

synchem@sbstaff2.cs.sunysb.edu (Synchem proj acct) writes:
    This reminds of of a question.  What's the relationship between MHEG
    and HyTime?  And between ODA and SGML?

The first question is a bit hard to answer, in particular, since
MHEG is still under development whereas HyTime has reached IS status in
the meantime. The most recent MHEG document I have available (June 92)
seems to indicate that MHEG has not reached a stable state yet,
since phrases such as "for further study", "to be completed",
"semantics to be defined", etc., appear at numerous places in the
document. My understanding of the document is that MHEG will use
concepts of HyTime. In particular, the coded representation of MHEG
objects may be based on SGML. (The alternative is ASN.1 which is also
used for ODA documents.)
The second question is probably a bit easier to answer but would require
a rather lengthy explanation for a more detailed discussion. (In fact,
this question has already discussed in various net groups.) I would
recommend "Computer Standards & Interfaces, Vol. 11, No. 3 (1991)",
in particular, the article "ODA and SGML: An assessment of Co-existence
Possibilities" from Watson add Davis therein. (If you can read German
you might also try "W. Appelt: Normen im Bereich der Dokumentverarbeitung"
in "Informatik-Spektrum, Vol. 6, S. 321-330, 1989".)


A.Grant@ucs.cam.ac.uk (Alasdair Grant) writes:

    And why include time in ODA when time is part of MHEG? Can't you converge
      a) MHEG
      b) ODA
      c) Group 4 fax, i.e. T.73 TIF.0 and TIF.1
      d) IPMS message bodies
    By all means let's have 'profiles' to extract subsets of a common standard
    for use in fax, e-mail, etc. Surely this is better than having four

    ... (some text eliminated)

    What form does the collaboration between ODA and MHEG take? Is it simply
    a case of duplicating functions? Or is MHEG going to become an application
    of (the new) ODA, in the way that HyTime is an application of SGML? (Or,

Firstly, a more general comment. In an ideal world, there would only
be one standard for each application. Unfortunately, and I personally
regret that very much, this is not the case for various reasons. Sometimes
a group of people simply does not know that another group is already
working on a standard in their area, sometimes people get into a sort
of religious war on the right approach for a standard and just don't
want to take other people's work into account, and, last not least,
there is often a lot of money involved, i.e., a manufacturer may have
very strong financial interests to make his system *the* Standard.
Having become a bit more realistic within the last years, I believe
that
(a) we should try as hard as possible to avoid overlapping standards,
but when (a) fails for whatever reasons,
(b) we should at least try to align the concepts between different
    standards to achieve interoperability between them.

To be more specific: This week there is a MHEG meeting in London with
participation from ODA experts. (I cannot attend this meeting.)
According to the discussion we had in June, ODA documents or parts
thereof may be used as MHEG objects and, vice versa, MHEG objects may
be parts of ODA documents. (Things may be clearer at the end of this
week.) This outlines already a possible dilemma: Since ODA can
neither be considered a subset of MHEG nor MHEG a subset of ODA,
a certain duplication of functionality is probably unavoidable,
e.g., I think that the concept of time is required in both standards
but I hope that (b) can be achieved.

I also support the view that profiles should be used to increase the
convergence of different standards. In fact, as two recent studies
have shown, ODA profiles in conjunction with SGML DTDs could
significantly increase the interoperability between ODA and SGML
systems.

Wolfgang Appelt
German National Research Center for Computer Science
St. Augustin
Germany