Subject: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate

From: "Doug Ewell" <[email-masked]>
Date: Fri, 27 Oct 2006 21:29:43 -0700

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> FYI, mainly for our editors.        Martin.

If I use the online XML2RFC, do I get the new boilerplate for free?

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
(still waiting for next 4646bis draft before I can do mine)
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 27 Oct 2006 21:33:25 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> And the key question here is whether this WG is willing to produce a 
> coherent framework for handling phonetic / phonemic transcriptions in 
> general, or would prefer to give a partial solution that addresses the 
> most widely-used one, namely IPA.  If the WG goes the general route, 
> then the question of how much information (phonetic vs phonemic, 
> transcription "system", etc.) needs to be encoded in the subtag(s) 
> should be decided.

I'm all for using the framework we already designed into the 4646 
syntax: extension subtags.

The question of "how much information" would then be offloaded onto the 
individual or body creating the extension RFC.

---

From: Addison Phillips <[email-masked]>
Date: Fri, 27 Oct 2006 22:47:57 -0700

Yes. Or download the darned thing. The Tcl/Tk interface makes generating 
a new copy even easier than the Web interface. And, in your case, avoids 
the Really Big Upload.

 > (still waiting for next 4646bis draft before I can do mine)

You'll be waiting until the pub-freeze for IETF 67 ends.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Martin Duerst <[email-masked]>
Date: Sat, 28 Oct 2006 16:10:59 +0900

>If I use the online XML2RFC, do I get the new boilerplate for free?

Contrary to Addison, I'm not sure. First, as of today,
http://xml.resource.org/ still has version 1.31; you have to
wait for the announced 1.32. Second, please check whether you
need to change the attribute ipr="full3978" in the <rfc> element
(top).

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 28 Oct 2006 09:40:48 -0700

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> http://xml.resource.org/ still has version 1.31; you have to wait for 
> the announced 1.32.

There is a version 1.32pre2 available at 
http://xml.resource.org/experimental.html, with suitable warnings about 
being a development version and living on the edge and so forth.  The 
text claims that this version supports the new boilerplate.  I suppose I 
could use both, then compare the outputs and make sure there are no 
undesired differences.

> Second, please check whether you need to change the attribute 
> ipr="full3978" in the <rfc> element (top).

To what?  "full4748"?

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 28 Oct 2006 09:53:52 -0700

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> Yes. Or download the darned thing. The Tcl/Tk interface makes 
> generating a new copy even easier than the Web interface.

I remember investigating this over a year ago, and balking at the idea 
of installing a new scripting subsystem.  Probably it reminded me of the 
MKS or Cygwin approach of "completely convert your Windows machine into 
a Unix lookalike."

> And, in your case, avoids the Really Big Upload.

I solved the RBU problem by uploading from home, using cable modem 
instead of the "faster" T1 at work.

> You'll be waiting until the pub-freeze for IETF 67 ends.

Thanks, I had forgotten about the freeze.  I'm still surprised that list 
discussion on these proposed changes has dropped to almost zero.

---

From: Addison Phillips <[email-masked]>
Date: Sat, 28 Oct 2006 11:10:36 -0700

> MKS or Cygwin approach of "completely convert your Windows machine into 

I've found that Tcl is more-or-less and install-and-forget experience. 
I'm on my third or fourth machine since starting to use xml2rfc. 
Basically, I just download the ActiveState Tcl for Windows, install it, 
and run xml2rfc. It hasn't interfered with anything else, especially 
since I don't use Tcl for anything.

In fact, this morning I had to go looking for the darned thing just to 
remember what it was called! I Yahoo-ed "tcl" and "Windows" and it's the 
first item.

Of course, my machine also has MKS, vim, and a host of Unixy things 
installed, so your experience may vary.

> discussion on these proposed changes has dropped to almost zero.

Yes. I'm sorry to have missed that particular deadline. But after it 
lifts I don't doubt that we'll make rapid progress.

Addison

---

From: Peter Constable <[email-masked]>
Date: Sat, 28 Oct 2006 22:39:17 -0700

As I suggested in the past, I think relegating transcription entirely to an extension would be undesirable because it would be ignored by any process that had no knowledge of the extension, which would be many. 

Or to put it in Randy's terms, in the case of a typical implementation accessing a server that had transcription and "normal" content, it would fail to deliver what the user wanted / fail to filter out unintelligible stuff.

What would work better would be to have a script-variant subtag for Latin-based transcriptions and have an extension to differentiate between different kinds of transcription / transliteration.

Peter

From: Doug Ewell [mailto:[email-masked]]

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 29 Oct 2006 12:33:56 -0800

I agree with Peter on this. When we were first talking about scripts, we
figured that we didn't need registered script variants -- that the script
group would be pragmatic enough. Perhaps we were wrong....

Mark

On 10/28/06, Peter Constable <[email-masked]> wrote:
>
> As I suggested in the past, I think relegating transcription entirely to
> an extension would be undesirable because it would be ignored by any process
> that had no knowledge of the extension, which would be many.
>
> Or to put it in Randy's terms, in the case of a typical implementation
> accessing a server that had transcription and "normal" content, it would
> fail to deliver what the user wanted / fail to filter out unintelligible
> stuff.
>
> What would work better would be to have a script-variant subtag for
> Latin-based transcriptions and have an extension to differentiate between
> different kinds of transcription / transliteration.
>
>
>
> Peter
>
>
>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 Oct 2006 22:15:32 +0100

Doug Ewell wrote:
 
> http://xml.resource.org/experimental.html, with suitable warnings
> about being a development version and living on the edge and so forth.

These pre-releases are generally fine.  Sometimes new features are
kicked in the next stable version, but that won't affect the newest
"fullsh*t" legalese (perfectly harmless this time, it only replaces
ISOC by the new IETF Trust).

> "full4748"?

LOL, no, not this time.  Once bitten (3678 => 3978) twice shy.  If
you don't like the xml2rfc pre-releases stick to the stable version.

Brian wrote that "old" boilerplates will be still accepted for four
months, a stable xml2rfc 1.32 will be released in time.  Nothing to
worry about if you use one of the two online versions for 4645bis.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 Oct 2006 22:29:28 +0100

Addison Phillips wrote:

> I Yahoo-ed "tcl" and "Windows" and it's the first item.

Blasphemy in two completely unrelated religions... <beg>

> I don't doubt that we'll make rapid progress.

Apparently we have consensus to use the new boilerplate
when available.  Okay, it's one of my more sarcastic days.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 29 Oct 2006 23:21:18 +0100

Peter Constable wrote:
 
> As I suggested in the past, I think relegating transcription entirely
> to an extension would be undesirable because it would be ignored by any
> process that had no knowledge of the extension, which would be many.

Why's that a bad thing ?  My use case would be Latn dictionaries, and I
won't care which phonetic alphabet they use.  Probably they also offer
wav-files.

> Latin-based transcriptions and have an extension to differentiate
> between different kinds of transcription / transliteration.
  
I don't see why that's better.  With a variant subtag "slbtgsei" (some
Latn based transcription gibberish, see extension info) plus extension
t-whatever you get tags like en-slbtgsei-t-whatever

That's longer than en-t-whatever, where or why would it work better ?

With a script-variant "Latt" (Latn transcription specified elsewhere)
a tag en-Latt-t-whatever could be even harmful, if it's my use case of
a dictionary, and I could read its Latn-parts - but never get it if I
filter out "Latt" as "non-Latn".

Frank

---

From: Felix Sasaki <[email-masked]>
Date: Mon, 30 Oct 2006 15:09:50 +0900

On Sun, 2006-10-29 at 23:21 +0100, Frank Ellermann wrote:
> Why's that a bad thing ?  My use case

In this thread, I saw a use case from Peter about linguistic data which
might benefit from information about the choice of a transcription
system. Are there other concrete use cases? Could you list them, and if
possible, a list (or a link) about (even if potential) possible values?

Such a "bottom-up" approach might make it easier to see whether this
information needs to be provided as part of a language tag or could be
in a different field (or e.g. XML attribute which is not xml:lang).

Felix

>  would be Latn dictionaries, and I

---

From: Peter Constable <[email-masked]>
Date: Sun, 29 Oct 2006 22:02:39 -0800

Let's say you have a dictionary for English: most of the content of a
given lexical entry is in the common orthographic writing system, and
one portion of the entry is in phonetic transcription. So, most of the
content is tagged en-US (or en-GB -- whatever), and the bit of phonetic
transcription is tagged (suppose) en-Lphn-t-ipa. How is that harmful? If
you search for en-US content, you'll get what you ask for. 

On the other hand, suppose I'm searching for English content, but I
really don't want phonetic transcription because it's all gibberish to
me. If a site has a corpus of texts in phonetic transcription but
they're all tagged en-t-ipa and the tools basically ignore the extension
because they know nothing about it, then I get returned to me all that
gibberish I'd rather not have to deal with. But if that same content
were tagged en-Lphn-t-ipa, then those same tools *do* understand that
Lphn is not the same as Latn and can filter out that content I don't
want.

Peter 

-----Original Message-----
From: Frank Ellermann [mailto:[email-masked]] 
Sent: Sunday, October 29, 2006 2:21 PM
To: [email-masked]
Subject: [Ltru] Re: IPA as a script

  

Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 30 Oct 2006 12:01:13 -0800

Hi -

As a technical contributor...

> From: "Felix Sasaki" <[email-masked]>
> To: "Frank Ellermann" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, October 29, 2006 10:09 PM
> Subject: Re: [Ltru] Re: IPA as a script
...
> in a different field (or e.g. XML attribute which is not xml:lang).
...

The case I had in mind is similar to what Peter decribed.

In an earlier career, I worked with fairly large bodies of linguistic data.
Some corpora consisted of transcriptions of spoken language.  Unlike the case
of a dictionary, where the transcriptions are only part of the content,
these documents are almost entirely transcribed language, and in general
do not carry that content in non-transcribed form.  (There might be ancillary
information identifying the transcriber, the date, setting, informant, and
so on, but almost never would one see the "content" represented in conventional
orthography in addition to the transcription.)

Some of the difficulties:
    - knowing which transcription system was in use for a document
    - knowing whether the transcription was broadly or narrowly phonetic or phonemic
    - sometimes a document would in general be phonemic, with only the "interesting"
      parts in narrow phonetic transcription.

I think this last problem fits in with the problem of "pronunciation" guides in
dictionaries, and we can't fix it here.  The first two, however, I think are
things we could address.  Now, the more fundamental question Felix raises
is whether this information should be carried in a distinct attribute.

Way back when we debated the addition of the script subtag the question was quite
similar: should this be regarded as another attribute, distinct from the language.
I still find this approach intellectually appealing.  However, pragmatic
considerations seem to have swayed the WG to pursue its current course
of encoding these dimensions by using multiple subtags.  Unless there is something
about transcriptions that makes them fundamentally different from scripts,
orthographies, and regionaly variations, it would probably make sense for
us to handle them in the same general framework.

Randy

---

From: John Cowan <[email-masked]>
Date: Mon, 30 Oct 2006 17:56:29 -0500

Randy Presuhn scripsit:

> Unless there is something about transcriptions that makes them
> fundamentally different from scripts, orthographies, and regional
> variations, it would probably make sense for us to handle them in the
> same general framework.

Note, however, that variant subtags need not represent regional variations
(dialects in the strict sense).  They may, for example, represent changes
in orthography (1901, 1990), jargons (boont), sociolects (Rumantsch Grischun
would be an example), or almost anything else.

I propose that one new script subtag "phonetic transcription" be
specified, analogous to "Brai" for Braille transcription, and that
variants be registered to specify particular cases like intphon-broad and
intphon-narrow.

-- 
John Cowan                                <[email-masked]>
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    -- Calvin, giving Newton's First Law "in his own words"

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 30 Oct 2006 15:17:20 -0800

I think that's headed in the right direction. However, I doubt that the
proposed tag would be viewed as a legitimate script. It might have a better
chance as Lati (Latin script variant, with the addition of phonetic
characters from IPA, etc.). (Corresponding script variants for other scripts
could be added as needed.)

Mark

---

From: Felix Sasaki <[email-masked]>
Date: Tue, 31 Oct 2006 14:28:30 +0900

Hello Randy, all

Thank you very much for you explanations. A comment below.

> us to handle them in the same general framework.

The only difference I see is a use case, i.e. for SSML, see
http://www.w3.org/TR/speech-synthesis/#S3.1.9 . You will find the following:
"The alphabet attribute is an optional attribute that specifies the
phonemic/phonetic alphabet."
An example from SSML:
<phoneme alphabet="ipa" ph="t&#x259;mei&#x325;&#x27E;ou&#x325;"> tomato
</phoneme>
The current definition of the alphabet attribute in SSML does not rely
on a registry for values, but that might be a topic for the future of
SSML. Hence, I would be worried if the LTRU WG and others (e.g. within
W3C) double their efforts (i.e. creation of registries) with overlapping
purposes.

In the context of SSML, it makes sense to have a separate field.

Felix

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 31 Oct 2006 11:03:45 +0100

Peter Constable wrote:
 
> transcription is tagged (suppose) en-Lphn-t-ipa. How is that harmful?

It's fine, I thought you wanted to tag the complete document as "Lphn".

And Felix' SSML example is also nice - certainly better than WAV files -
if and when it's supported by popular browsers.  This example is however
about an element <phoneme> in its own namespace, not about the attribute
xml:lang used everywhere.

> If a site has a corpus of texts in phonetic transcription but they're
> all tagged en-t-ipa and the tools basically ignore the extension
> gibberish I'd rather not have to deal with.

Yes, assuming that applications will support "Lphn" but not "t-ipa",
I've
no idea what server and browser implementors plan.  I'm also not sure
why
you would want "Lphn" instead of "Aphn" (A = any), but if it's in the
position of a script subtag that's an issue for a "script-variant-list",
or however that's organized, I didn't study all details of the 15924
page.

Maybe the LTRU WG could somehow "officially" state that some "Lphn" or a
similar solution would fit into the 4646 language tag scheme, but I'm
not
sure about that idea.  If you want an LTRU resolution to reserve "Lphn"
I'd abstain - I can't tell if "Lphn" is zero, one, or more scripts.  I'd
bet "not one script" if forced to bet, that leaves zero or more.

Frank

---

From: Marion Gunn <[email-masked]>
Date: Tue, 31 Oct 2006 11:51:01 +0000

It has taken years to catalogue 1,000 upon 1,000s of IPA entries,  
which I did by dint of rewriting the first line of each in "normal"  
script(s) - now this material must be digitized: keyed in as written  
(in IPA) for sorting and contextual searching that way. Those keying  
it in do not necessarily come equipped with the ability to do as I  
did (above). Among the projects the material is urgently needed to  
serve, two have to do with synthesized speech. If anyone can think of  
how to do this and share online by being able to mark it as being in  
IPA script, then perhaps he/she would enlighten those of us who need  
this service.
mg
- -
Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *

---

From: Peter Constable <[email-masked]>
Date: Tue, 31 Oct 2006 05:06:22 -0800

> It's fine, I thought you wanted to tag the complete document as
"Lphn".

??!!

> I'm also not sure why
> you would want "Lphn" instead of "Aphn" (A = any),

I think it's important to reflect the script that the transcription
system is primarily derived from. Most I'm aware of are based on Latin,
though I met one Korean linguist using an extension of Hangul for
phonetic transcription. So, something like "Lphn" or "Latp" would be my
suggestion.

> not sure about that idea.

That is certainly something I'd consider. This WG owns the 4646 LT
space, so if it seems like the sensible solution to us and the 15924 JAC
won't budge, we can ask them to reserve an ID.

Peter

---

From: Marion Gunn <[email-masked]>
Date: Tue, 31 Oct 2006 14:20:38 +0000

On 31 Oct 2006, at 13:06, scríobh Peter Constable:
> system is primarily derived from...

Why? And why complicate matters so? On the basis of what you have  
said above, how would you categorize a combination of Latin and  
Cyrillic?:-)
mg

- -

---

From: Marion Gunn <[email-masked]>
Date: Tue, 31 Oct 2006 14:42:13 +0000

Historically speaking, to _underline_ the distinction between issues  
to do with charsets and issues to do with scripts, which can, to some  
LTRU list readers, seem fuzzy: a thousand years ago, Tironian Et  
("7") was no more than a part of a Roman/Latin system of notation,  
but to Irish people today, it is seen as a quintessential part of our  
traditional charset (most of us simply wouldn't associate it with any  
other language, even Latin!), so, bearing in mind that getting  
Tironian Et codified was a character set (non-script) issue which  
should probably never have been handled by ISO not as a character set  
issue in and of itself, but as a simple giorrúchán (contraction) -  
something which our understanding at the time may not have permitted  
- IPA goes way beyond that because, to users (linguists) on the  
ground today, as we speak, IPA is seen as a handy alternative script  
(professional system of notation), that is, a tool serving more  
languages than our own.
mg
- -
Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *

---

From: Peter Constable <[email-masked]>
Date: Tue, 31 Oct 2006 11:29:03 -0800

Because if we have a single subtag that means simply "some system of phonetic transcription", then e.g. I'm not going to find it helpful to get results in a Hangul-based transcription that I can't understand; or, e.g., it's not going to be really helpful to a Korean linguist to get a ton of Latin-based phonetic transcription when what they're looking of is Hangul-based transcriptions. Systems of phonetic transcription I'm aware of are base primarily on one script; since we're talking about a script / script-variant subtag, it's appropriate IMO to reflect what that primary script is.

Do you know of a specific system of phonetic transcription that is derived equally from Latin and Cyrillic or is that just a hypothetical scenario? (I suspect the latter.)

Peter

-----Original Message-----
From: Marion Gunn [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2006 6:21 AM
To: [email-masked]
Subject: Re: [Ltru] Re: IPA as a script

- -

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 31 Oct 2006 13:47:34 -0800

I agree with Peter. If someone wants English written in some Hangul
transcription, or Korean written in some Latin transcription, that already
exists: en-Hang and ko-Latn. Now, one might want to have a further
specification, "Korean written in Latin transcription according to the
Ministry of Education Transliteration with Rule 8"; that would be a futher
refinement of ko-Latn, and that might be a possibility for an extension. But
at a high level, Korean written in some Latin transcription can already be
described.

What we don't have any way of expressing is English written in IPA or Korean
written in IPA (or less common ones such as Finno-Ugric or Americanist).

en-XXXX, where XXXX means that the 'en' is written in "some phonetic
transcription but we're not going to tell you what script it is based on", I
don't think would be particularly useful at all.

Mark

On 10/31/06, Peter Constable <[email-masked]> wrote:
>
> Because if we have a single subtag that means simply "some system of
> phonetic transcription", then e.g. I'm not going to find it helpful to get
> results in a Hangul-based transcription that I can't understand; or, e.g.,
> it's not going to be really helpful to a Korean linguist to get a ton of
> Latin-based phonetic transcription when what they're looking of is
> Hangul-based transcriptions. Systems of phonetic transcription I'm aware of
> are base primarily on one script; since we're talking about a script /
> script-variant subtag, it's appropriate IMO to reflect what that primary
> script is.
>
> Do you know of a specific system of phonetic transcription that is derived
> equally from Latin and Cyrillic or is that just a hypothetical scenario? (I
> suspect the latter.)
>
>
> Peter
>
>