🚀 go-pugleaf

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