Re: consuming the semantic tag (was Re: Subscripts in Content MathML)

In some sense it comes down to server side versus client side kinds
of options.  ... and I will ignore the parallel markup issues for now.

There will always be a variety of clients whether it be CAS or passive
browser - computational versus passive viewer.  For a variety of reasons
some of those clients will not be able to make use of the full richness
of all the data that the server provides or can provide.

Either the provider of the data pre-computes and provides the alternative
markup or the client computes it. Neither side can generate markup that
depends on information that is not there.

The provider of the data (server side) can either provide multiple
documents or multiple markups in one document.  The latter is essentially
using the semantic tag.  It is passive in that the server need not know
anything about the client.

If the server  provides multiple documents, then the server must
have some way of knowing which version of the document to send to a
particular client.  In contrast, the semantic tag allows the server to
merge all those documents into one and leaves it to the client to choose
a representation it can handle.  The client may even choose different
representations on different expressions, or for different purposes
(perhaps a right-click/select option)

While the mime-type warns the client what is coming, it only applies to
the whole document - not individual expressions, and it is the wrong
way round.  We want a client to be able to say send me X - not "Oh!,
I can handle X. :)".

I see the following main concerns:

1) Because the semantic tag is very verbose (sending lots of information
that may not be used) there needs to be a way of sending a particular
client only what they can handle.  The device needs to be able to announce
what it wants. (The server could then pre-filter the document for them.)
This is more like multi-language support than mime-type.

2) There is no easy way for a client to choose a particular representation
from the semantics tag.  (Choice by order doesn't cut it and there is
no systematic way at present to label a markup by role or purpose)

Both would be addressable by a systematic labelling scheme for the
expressions in the semantics tag - perhaps a kind of a URI scheme.

TODO:  I think we should add "cleaning this up" to the list of things to do.
(and perhaps content negotiation analogous to language negotiation)

Stan

See my additional remarks below:

On Tue, Oct 11, 2005 at 06:13:44PM +0200, Paul Libbrecht wrote:
> Stan,
...
> 
> The issue I have with the semantic tag is how to specify which semantic 
> tag to take ?
> 
Agreed.

> Indeed, your extended sum-with-elipsis would fit if the client 
> application would support it and should be converted to an official sum 
> if not.

Server side or client side ?

> So we would have at least the following flavours:
> - matml-content:official-symbols
> - mathml-content:official-symbols-plus-some-more-of-system-x
> - 
 ... only I would use a uri like attribute on the expression 

> mathml-content:official-symbols-plus-some-more-of-system-x-and-system-y
> Are these "sets-of-symbols" (somewhat equivalent to OpenMath cdgroups) 
> well and declaratively defined ? Should they be part of mime-types ??
>   application/xml+mathml-content+some-more-of-x
> This would integrate in such exchange systems as copy and paste or 
> drag-and-drop.
> 
Why wouldn't cut and paste select from all the available expressions?  
(Again, the expression type label would be needed )

> I have a further complaint about the semantic-element: they're 
> expensive! If you start having at least, say, two 
...

1.  You still need the labels on the terms in the semantics tag if
the server is to be able to strip down a  "merged" document to 
satisfy a particular request.

2.  The client must have some mechanism to be able to ask for a 
particular version.  This is very analogous to the multi-language support 
for which there are fairly standard methods that can be borrowed.
The difference here is that you will often want multiple languages.

> 
> paul
>

Received on Wednesday, 12 October 2005 10:46:27 UTC