William Overington scripsit:
> Well, it depends what one is trying to do. If one wishes to establish a
> system whereby proprietary intellectual property rights exist, then a
> proprietary coding can be a good idea.
That is the function of encryption.
> >XML is the way to go.
>
> Maybe, maybe not. The issue of U+003C being used to mean LESS-THAN SIGN in
> documents which mix ordinary text and markup may or may not, depending upon
> the application, be a problem.
Since there are several standard ways to represent the semantic LESS-THAN
SIGN in XML ("<" is most typical, but "<" also works), there is
no problem, only a little extra work as tradeoff. After all, why not
invent your own character code as well as your own markup language?
> The keys idea is pushing the envelope. As spin off from this discussion,
> maybe the XML people, and the Unicode Technical Committee, will do something
> about having special characters for the XML tags rather than using U+003C
> and thereby help people wanting to place mathematics and software listings
> in the same file as markup.
MathML is a markup standard for mathematical text that is an application of
XML, so people "wanting to place" etc. need no further help.
Don't hold your breath, and don't *mutcheh* us about it.
> What is wrong with private encodings?
Interchanging them does not scale.
> People may ignore them if they wish.
They will, they will.
> High level application semantics assigned to particular code points are
> potentially very useful. I have published various documents on the web
> about them with Private Use Area allocations for various items such as
> colour and point size for text.
Of course you can use the Private Use Area for whatever you like. A character
standard, however, is intended for encoding *characters*. It is not intended
as a source of useful integers -- for that, apply to Dedekind.
--
John Cowan [EMAIL PROTECTED]
"You need a change: try Canada" "You need a change: try China"
--fortune cookies opened by a couple that I know
