[gmpi] [OT] Re: Topic 7.1: Channel Formats / XML, Profiles

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 6 Jun 2003 12:19:20 -0700

Steve said:

Chris Grigg wrote:
Steve wrote:
> >Think of SGML v's XML. SGML supported /everything/ whereas XML supports
 >the bare minimum of functionality. Because SGML was so complex it never
 >took off. In 5 years XML has got massively wider adoption that SGML did in

 XML is the example that proves why parameterization does not kill
 standardization efforts, but rather reinforces them, and is therefore
 worth the trouble.  In fact, XML is -highly- parameterized, which is
 its strength, and the key to its ability to adapt tightly and
 appropriately to many different applications, and that (in addition
 to human/machine readability) is exactly why it's successful, and why
 it'll probably be a stable, durable basis for products for many years
 to come.  We could learn from XML.

No, this is not a reasonable analogy. The equivalent would be that arbitrary subgraphs could be in arbitrary cacharcter sets. That was banned in XML.

You seem to assume I'm advocating that a single GMPI graph would be required to support multiple per-sample encodings at a given time. Since I'm not, could you reconsider the above?

For XML, we had SGML and tried to chip away all the cruft to be left with
something minimal.

Well, not strictly minimal. If XML were strictly minimal, it would not support both UTF-8 and UTF-16. I think Paul got it right, it's more that in XML a more useful and viable balance was struck than in SGML.

As I said to Paul: "It goes without saying that GMPI should have an appropriate feature set. Merely saying that in the SGML->XML evolution the feature set was focussed doesn't give us any useful guidance in how to specifically focus the GMPI feature set. In particular, it doesn't help us evaluate whether parameterizing per-sample encoding is likely to be more helpful or more harmful." My point was that in the very process you cite of evolving SGML into XML, it was determined that parameterizing the character set was a useful flexibility to have, since different systems use different character sets -- i.e. was useful enough to justify the architectural and implementation complexity and developer education required to support it. I think the parallel to parameterizing GMPI's per-sample encodings is clear and compelling.

> In XML, there is no such thing as a generalized XML parser; XML is
 only an underlying technology model, not an application, and XML only
 becomes a usable application when combined with a DTD or schema

Not true, one of the most important simplifications in XML was the concept of a well-formed document. The vast majority of XML is well-formed, but not valid (ie. it has no DTD or schema, but it still interpretable).

While a good thing from an integrity-check POV, well-formed is not useful in terms of the fundamental purpose of XML, i.e. interoperable communication of information relevant to a specific application area. Knowing that an XML chunk is well-formed is not much help in parsing the meaning a MIDI Names document. To do that eficiently, you need some knowledge of the dialect, either hard-coded or via a DTD or schema. See previous response to Paul: "...I meant that a generalized XML parser is pretty useless for a particular practical purpose or interoperability of a particular XML dialect without a DTD or schema defining the dialect. I meant to imply a parallel with GMPI, to acknowledge that the more things we parameterize in GMPI, the more general it would become, and therefore the greater the need for definitions akin to DTDs would be. Which motivated the idea of profiles that followed."

I think all of the above illustrates that the XML->SGML case is more complex and supple than your initial argument allowed for, and on its own not enough of an argument against parameterizing per-sample encodings. But feel free to continue with other arguments against, or to extend this one.... 8-)

Here we have things like VST that were trying to chip
away cruft from.

Cruft can be defined not only as unnecessary functionality, but also as excessively limiting assumptions.

I've not seen any evidence that (in audio buffer terms)
VST isn't functionally complete - granted it has inadequet parameter
representation but were discussing buffers here.

Unless you can demonstrate that audio representation /requires/ something
other than PCM float then it's cruft.

Others have argued for both 32's and 64's, and as Vincent has pointed out there are domains beyond MIDI+Audio sequencers where GMPI could potentially be a useful technology, but where other per-sample encodings (even integer) are used natively and are sufficient. So this whole area seems to me like a question of defining where we want GMPI to work in the near-term. And also how long-term we want GMPI to remain viable without having to rip out the foundations -- i.e. ability to move to a different per-sample encoding in the not-too-unlikely event the world changes in the future, or that we know more in the future than we do today.

Looking at this from a high-level procedural POV -- If the group decides that we only care about addressing the kinds of applications that VST addresses today, then I can live with that... but that's not what the current scope says we're supposed to be addressing. If the group decides that this kind of future adaptability is not worth providing, then I can live that... but there has been no such decision to date.

However if both of these decisions tilt toward the quick and easy-for-now solution, I will see GMPI as a less valuable project than I have hoped for. And that would be a shame.

-- Chris G.

Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: