From: William Overington (WOverington@ngo.globalnet.co.uk)
Date: Wed Jul 16 2003 - 06:33:07 EDT
Peter Constable wrote as follows.
>William Overington wrote on 07/15/2003 05:33:22 AM:
>
>> >William, CENELEC is an international standards body. Such bodies either
>> >create their own standards or use other international standards. They do
>> >not use PUA codepoints.
>>
>> Well, the fact of the matter is that Cenelec is trying to achieve a
>> consensus for the implementation of interactive television within the
>> European Union
>
>And that does not require PUA codepoints; moreover, your response does not
>escape the fact I was pointing out that a standards body will not be
>publishing standards that make reference to PUA codepoints.
Please have a look at what Cenelec is do in trying to achieve a consensus
for the implementation of interactive television within the European Union.
This particular project for the European Commission is trying to achieve a
consensus for the implementation of interactive television within the
European Union. Your comments seem to relate to standards bodies generally
or as to how Cenelec proceeds generally. This project is a particular
project trying to achieve a consensus for the implementation of interactive
television within the European Union. The difference is that things need to
move forward promptly. There are lots of aspects, such as how many buttons
to have on a hand-held infra-red control device for end user interaction
with a running Java program (that is, the _minimum_ twenty of the DVB-MHP
specification, or some more) and such as whether mouse events should be
accessible to end users (as the DVB-MHP specification has mouse event access
as optional in interactive televisions) and so on.
What you write in relation to most projects carried out by standards bodies
may well be true, yet I was writing specifically about one particular
project being run by Cenelec.
>> In view of the fact that the interactive television system (DVB-MHP,
>Digital
>> Video Broadcasting - Multimedia Home Platform http://www.mhp.org ) uses
>Java
>> and Java uses Unicode it is then a matter of deciding how to be able to
>> signal the symbols in a Unicode text stream.
>
>And they won't be standardizing on symbols encoded using PUA codepoints.
The "deciding" is not about something to incorporate into the DVB-MHP
standard. It is a matter of trying to gain a consensus as to how to signal
those symbols at the present time and in the near future (that is, until (if
and when) some regular Unicode code points are achieved) within Java
programs which run upon the DVB-MHP platform and in fonts which are used
upon the DVB-MHP platform. It is essentially a matter for end users of the
system, just as the two Private Use Area characters being suggested in
another thread of this forum in relation to Afghanistan are a matter for end
users of the Unicode Standard and does not affect the content of the Unicode
Standard itself.
>> In view of the fact that the process of getting regular Unicode code
>points
>> for the symbols would take quite a time, and indeed that there is as yet
>no
>> agreement on which symbols to use, and that the implementation of
>> interactive television needs to proceed, it seems to me that putting
>forward
>> three specific Private Use Area code points for the symbols at this time
>is
>> helpful to the process.
>
>Then you obviously don't understand the process.
Well, maybe I don't. However, the fact of the matter is that sooner or
later some code points are needed to signal those symbols. I have put
forward three suggested code points. I also mentioned them in this mailing
list. My specific suggestions are in the Private Use Area and do not clash
with various uses of the Private Use Area known to me. So three specific
code points have been mentioned and I suggest that having those three code
points published both in the Cenelec forum and here is beneficial as if they
are used then various potential problems which could have arisen if some
other choices (such as three unused code points in regular Unicode or
several different sets of three code points in regular Unicode) were used.
>> >Such things are *not* useful. They do not achieve consistency, not in
>the
>> >short term, and most certainly not in the long term. If consistency is
>> >needed, the standardization process is used to established standardized
>> >representations.
>>
>> Well, what is the alternative?
>
>The alternative to agreeing on a standard? None, but why would you need an
>alternative?
Code points for the symbols are needed now or in the near future. The
symbol designs are not yet agreed. Obtaining regular Unicode points, if
achievable, would take quite a time. With my suggested code points
published, decisions on which symbol designs to use and getting them into
use with everyone using the same code points could happen within a few days.
>> The code points are in the Private Use Area,
>> so the suggestion avoids the possibility of a non-conformant use of a
>> regular Unicode code point.
>
>That is hardly the concern. Standards are designed to be international
>agreements that foster international commerce; such IT standards are
>intended to be international agreements on data representation or
>processing protocols on which interoperable products can be developed. In
>order to ensure reliable interoperation, they will not build standards on
>anything that isn't standardized. PUA codepoint usage is not standardized,
>by definition.
The Java programs which use the code points can be changed if and when
regular Unicode code points are agreed. The Java programs are broadcast,
which means that everyone is using the latest version.
>> For the long term, hopefully regular Unicode
>> code points will be achieved. In the short term, my suggesting of some
>> specific code points does not impede consistency and may possibly help to
>> achieve consistency.
>
>Wrong. There is no consistency if company A decides to follow one set of
>PUA character assignments while company B uses a different, incompatible
>set. As long as PUA codepoints are used, that is going to be at stake.
Certainly your comment "There is no consistency if company A decides to
follow one set of PUA character assignments while company B uses a
different, incompatible set." is correct.
You also write "As long as PUA codepoints are used, that is going to be at
stake.". Well, maybe it will and maybe it won't. The issue is getting the
task achieved. The issue of which specific code points to use is not
critical as long as they are in the Private Use Area and do not clash with
other known possible uses of the Private Use Area for broadcasting.
I know that you have various Private Use Area codes for some of your work.
I hope that these codes do not clash with what you are using (of which code
point allocations I am currently unaware) because I am hoping that DVB-MHP
will be widely used and therefore use of any allocations which you have made
in the Private Use Area on the DVB-MHP system is a possibility.
>> However, publishing Private Use Area code points as an interim solution
>is
>> an established process.
>
>I think I'm about to set up that "default-ignorable post" rule.
Well, that is a matter for you. However, I made a short post providing some
information which I hope some people found of interest. I have tried to
answer comments which have been made.
>> These symbols seem to be as valid as many of the symbols already in the
>> Miscellaneous Symbols section and as valid as those currently going
>through
>> the registration process. In view of the excellent .pdf files which have
>> appeared about those symbols which are presently going through the
>> registration process I am rather hoping that these symbols will at some
>> future time appear in such a .pdf file as part of the registration
>process.
>
>Your and our time would be much better spent if you were contributing to
>getting the set of symbols finalized and getting proposal documents
>prepared to have them added to ISO 10646 than by proposing PUA codepoints
>to members of this list.
I simply posted a short note to this mailing list. Certainly I am happy to
respond to issues which have been raised yet had no one raised any issues
the post would have stood on its own. It was clearly labelled as [Private
Use Area] in a similar manner to the way that some posts in this list are
labelled [Off topic] or [OT}.
Getting the symbols finalized is certainly important, yet someone else is
doing that. Proposal documents are not needed as yet. When they are I
would be happy to help if that is wanted, though I am somewhat restricted in
what I can do in that regard as I do not have facilities for producing .pdf
files myself.
The defining of the code points and posting them in the Cenelec forum, and
later here, took some time though not a great amount. It is a small, yet
important, item within a much larger overall project of implementing
interactive television.
I have spent far longer in responding to posts in this thread, though I am
happy to respond to the issues which have been raised.
>> >And might I also suggest that you create a Yahoo discussion group or MSN
>> >community for PUA use, and then carry on discussion of ways to use the
>PUA
>> >there rather than here?
>>
>> Reading the information into the Unicode mail list archive is a process
>of
>> great value to me, so that is the motivation for posting the information
>in
>> this mailing list.
>
>I'm suggesting that you take your PUA discussions elsewhere so that the
>information value from the Unicode mail list can be maintained for the rest
>of us.
The thing is that you do not know as to whether some other readers of this
list enjoy reading my posts. In any case, it was a short post, clearly
labelled as [Private Use Area] and did not seek to start a discussion.
However, I accept that having posted the item it thus became a matter of
public interest and so when you raised various issues I am happy to respond.
>> I was not carrying on a discussion of ways to use the PUA. I was simply
>> making an announcement to the people on the list. There may well be
>people
>> on this list who are interested in interactive television and who are not
>> members of the Cenelec discussion forum
>
>Wouldn't you have a greater likelihood of reaching your target audience on
>a forum dedicated to interactive television?
I have posted the suggested code points within the Cenelec hosted discussion
some time ago.
>> and who might like to know of this
>> suggestion. Also, the symbols might well be used in hardcopy television
>> programme listing magazines, so it would be desirable to have them
>available
>> in fonts.
>
>Think about the workflow for such magazines and then tell me again you're
>not suggesting PUA codepoints for use in interchange.
Well, I am here suggesting Private Use Area code points for interchange,
both in interactive broadcasting and in typesetting of magazines.
Where I was specifically not suggesting interchange of Private Use Area code
points was (in other threads) in the use of Private Use Area code points for
precomposed characters which are display glyphs for sequences of Unicode
characters, where such display glyphs are accessed using a eutocode
typography file.
The difference is that the accented Cyrillic characters are representable by
an existing regular Unicode sequence whereas the symbols for Audio
Description, Subtitle, Signing are not presently representable by an
existing regular Unicode sequence.
The implementation of interactive television involves many people. This
suggestion for some Private Use Area code points for use for Audio
Description, Subtitle, Signing within Java programs and fonts broadcast upon
the DVB-MHP platform is just one small part of the overall process.
Certainly the prospect exists that the symbols might be included in the
built-in font of interactive televisions within the Private Use Area. It is
a matter of practicality of moving forward before the time needed to get the
symbols encoded into regular Unicode has passed. Please know that the
DVB-MHP specification specifies the minimum font for a DVB-MHP television.
It remains to be seen what will be decided as the built-in font for the
European Union implementation of the DVB-MHP specification. It might be the
minimum font of the DVB-MHP specification or it might be more comprehensive.
For example, should Greek characters be included? Should weather symbols be
included? These and many other issues remain to be decided.
William Overington
16 July 2003
This archive was generated by hypermail 2.1.5 : Wed Jul 16 2003 - 07:18:19 EDT