Re: Reservations about <mchar>

Roger,

[this is a personal reply, not a group response]

> Perhaps XML should support
> a different class of inline-replaced "&&Entity;" that are not reported as
> an error if they are unresolved,

Such a syntax would require a change to XML itself, and break SGML
compatibility, so I don't think there is any real possibility of this.
The alternative to mchar is just using unicode data directly, which
is a possibility, and may be the normal behaviour of mathml writing
tools, but I think something like mchar is still needed to offer at
least the possibility of hand writing small MathML fragments with
the currently available tools.


* foster incompatibilities
  since the same char be known under different names depending on
  the usage and field of interest, it is hard to set a definitive list.

The current draft is unfortunately rather vague on this issue as the
lists of characters we were getting as part of the UTC discussions of
the unicode math characters were changing right up to the last minute
before we made the draft. However the intention is that the tables in
chapter 6 are (will be) the definitive definition of the allowable names
for mchar.

  With <mchar>, there wouldn't be a standard-compliant way for the 
  users to resort to that trick and use the most relevant names
  w.r.t. to their context.

Entities can be used for all sort of author short cuts and abbreviations
If the author uses a suitable <!DOCTPYE then these may still be used,
even if the replacement text of the abreviation is an mchar rather than
a character or entity reference. However use of such locally defined
entities does cause problems when moving fragments from one document to
another as you have to manage the merging of the entity sets.

* poor extensibility

As defined, mchar is not extensible at all.
Personally I'd like to see the use of some namespace mechanism
to allow more names, so either
<mchar xxx:name="yyyy"/> or <mchar name="xxx:yyy"/> where xxx: is a
namespace prefix in the current scope, and yyy is a new name determined
by that namespace. But the implications of allowing that kind of
extensibility (in either of these proposed forms) at this stage are not
clear as the general issue of namespace usage hasn't really settled
down. So currently mchar allows just the names specified in chapter 6.


* consume memory and slow to process

I didn't understand this argument. It is clear that having mchar means
that the name has to be resolved by the application rather than the xml
parser, so more information has to pass to the application. But in what
way would mchar be different from your &&foo; unresolved entity
proposal? You would still, in that case have to have some kind of
special node containing "foo" so that wouldn't be so different from the
elemen/attribute nodes would it?


David

Received on Tuesday, 2 May 2000 07:00:28 UTC