On deployment

The bracketed numbers are references to messages by number on the
mailing-list archive; the other bracketed references are given at
the end of this message.

---------------------------------------------- a separate content-type
[012] Dave Raggett writes:
> We discussed whether it was necessary to use SGML for the math notation.
> Basically, we have a preference for an extensible operator precedence
> notation. This can be included in HTML documents and handled correctly by
> SGML processing applications via the NOTATION mechanism. 

I agree that it's better to use an extensible notation independent
of SGML tags.  A successful design needs to bridge the gap between
easy writability/readability/maintainability and machine processability.
Operator precedence parsing is a major part of this.

If you are going to include a new syntax in documents, though, it
really doesn't seem like this is much different from how i am
deploying MINSE.  It amounts to a new Content-Type even if you
don't label it as such, and could be included either within its
own specialized tag or within an OBJECT tag referencing a URL of
that type.  The current implementation of MINSE allows both [USAGE].

------------------------------------------------------------- plug-ins
[071] Dave Raggett writes:
> ...that can be deployed
> with plug-ins or Java applets etc. by later Summer or early Fall.
[...]
> I would like to extend the plugin mechanism for browsers to support
> HTML math elements directly, and have some ideas for the transition
> issues this would involve.

Plug-ins are useful, but they are only one deployment method.
Creating an implementation that works only with plug-ins runs the
risk of being too browser-specific and platform-specific.  If we
were to make a plug-in available for one particular browser, that
would suddenly make it the only math-capable browser in existence.
It's nice to have plug-ins for more than one browser, and to have
alternatives like Java or a mediator [MEDIATOR].

The use of a mediator ensures that everybody will get to try this
out, and also lets authors choose to write their documents in a
way that will be ready for browser native support.

----------------------------------------------------------- references

[012] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00012.html
[071] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00071.html

[USAGE]    http://www.lfw.org/math/usage.html
[MEDIATOR] http://www.lfw.org/math/usage.html#pmpm


Thanks for reading!


Ping
The bracketed numbers are references to messages by number on the
mailing-list archive; the other bracketed references are given at
the end of this message.

---------------------------------------------- a separate content-type
[012] Dave Raggett writes:
> We discussed whether it was necessary to use SGML for the math notation.
> Basically, we have a preference for an extensible operator precedence
> notation. This can be included in HTML documents and handled correctly by
> SGML processing applications via the NOTATION mechanism. 

I agree that it's better to use an extensible notation independent
of SGML tags.  A successful design needs to bridge the gap between
easy writability/readability/maintainability and machine processability.
Operator precedence parsing is a major part of this.

If you are going to include a new syntax in documents, though, it
really doesn't seem like this is much different from how i am
deploying MINSE.  It amounts to a new Content-Type even if you
don't label it as such, and could be included either within its
own specialized tag or within an OBJECT tag referencing a URL of
that type.  The current implementation of MINSE allows both [USAGE].

------------------------------------------------------------- plug-ins
[071] Dave Raggett writes:
> ...that can be deployed
> with plug-ins or Java applets etc. by later Summer or early Fall.
[...]
> I would like to extend the plugin mechanism for browsers to support
> HTML math elements directly, and have some ideas for the transition
> issues this would involve.

Plug-ins are useful, but they are only one deployment method.
Creating an implementation that works only with plug-ins runs the
risk of being too browser-specific and platform-specific.  If we
were to make a plug-in available for one particular browser, that
would suddenly make it the only math-capable browser in existence.
It's nice to have plug-ins for more than one browser, and to have
alternatives like Java or a mediator [MEDIATOR].

The use of a mediator ensures that everybody will get to try this
out, and also lets authors choose to write their documents in a
way that will be ready for browser native support.

----------------------------------------------------------- references

[012] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00012.html
[071] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00071.html

[USAGE]    http://www.lfw.org/math/usage.html
[MEDIATOR] http://www.lfw.org/math/usage.html#pmpm


Thanks for reading!


Ping