Some responses below.
> Hi Carl, Wednesday (7 October 1998)
>
> My comments on appropriate use of Natural Language Override are imbedded
> in your (excerpted) note below.
>
> Cheers,
> - Ira McDonald (outside consultant at Xerox)
> High North Inc
> 906-494-2434
>
> >------------------------------------------------------------------------
> >[Note - I reformatted your paragraphs for legibility]
> >
> >From: Carl Kugler <kugler@us.ibm.com>
> >To: <ipp@pwg.org>
> >Subject: IPP> MOD OLD NEW Issue: Contradictory NLO requirements
> >Date: Wed, 7 Oct 1998 16:43:19 PDT
> >
> >While we're on the subject of natural languages, here is a rerun from
> >May. Bear with me on this one; it's hard to digest. I found it hard to
> >follow myself, after four months!
> >
> >Original message: http://www.egroups.com/list/ipp/3641.html
> >
> >Re: IPP> MOD> Another IPP 1.0 issue
> >By Carl Kugler @us.ibm.com
> >Friday May 29, 1998 11:42 AM PST
> >
> >I think this text from MOD section 3.1.4.1 is misleading:
> >
> >[snip...]
> >
> >Somewhat related question: is it ALLOWABLE for an IPP object to use the
> >Natural Language Override mechanism in cases where it is NOT necessary
> >(i.e., would be redundant with a default specified by a Job object's
> >"attributes-natural-language" value or the "attributes-natural-language"
> >operation attribute of the response)?
> >
> >[I think we're now saying yes, which implies that 3.1.4.1, while
> >misleading, is technically not incorrect. It just calls for more NLO
> >overrides than necessary.]
> >
>
> IEM - I believe it should always be permissible to insert an (otherwise
> redundant) NLO in a response or in the internal representation of the
> job's attribute on a server (ie, an IPP Printer object).
>
I think we now all agree that NLOs MAY be used even when redundant. It just wasn't stated anywhere in the 6/30 documents. But, do you see my point about self-inconsistencies in MOD regarding when NLOs MUST be used?
> >
> >P.S. Does it really need to be this complicated? Of what utility is
> >this NLO anyway? It has no use on the server side. The only use I can
> >think of at all is in choosing an orientation for rendering text for
> >individual attributes on a GUI. I'd be impressed to see a GUI that can
> >render a group of attributes with some sideways and some up-and-down,
> >and still make sense!
> >
>
> IEM - One use for NLO is an operator writing 'job-message-from-operator'
> on an existing queued job in a language OTHER than the language than the
> job was submitted with.
Why would the operator do that? Do we expect this to be a common scenario?
> Another use is for site-administered media names
> (eg, defined by the site SA in French, when submitting a job in German).
So we're going to allow the semantics of media name values to vary with locale? So, for example, "en-US","letter" might have dimensions of a x b centimeters but "en-GB","letter" has dimensions of c x d?
> Another use is for correctly specifying 'requesting-user-name' in the
> language of the job creator, even if the job (for site-specific reasons)
> is being submitted in another language (eg, all the key operators speak
> French and the office is in Zurich, but the job submitter is Swedish).
Do the semantics of 'requesting-user-name' values change with natural language? Aren't names, in general, naturally opaque? Example: say my 'requesting-user-name' is "en-US","carl". Isn't my name still "carl" regardless of my locale? Or do we expect Printers to match "en-US","carl" with "en-GB","charles" or "de-de","karl"?
>
> The W3C is now requiring explicit language tagging in most of their new
> standards work and the IETF (in RFC 2277, Policy on Charsets and
> Languages) strongly recommends language tagging in all new protocols,
> because speech synthesis (eg, screen reader software) REQUIRES language
> tags to correctly 'read' text. This feature is useful for people using
> limited mobile interfaces and for people in hostile environments (such as
> factories). It's obviously necessary for access by blind people.
Okay, this seems like a good reason. I just wonder if we really need to take it to the point of allowing each and every attribute to be specified with an independent language. How often is that flexibility going to be used? The complexity of this mechanism might actually reduce its deployment and defeat the whole purpose.
Whatever. I suppose it's too late to argue about whether or not we need NLO on a per-attribute basis. But surely there are some simplifications we could do to the model even now. Especially if you agree that it is currently broken.
>
> With respect to your remark about text with both horizontal and vertical
> elements (in a GUI or other WYSIWIG interface), actually the Unicode
> Consortium (which has already published an excellent bi-directional
> algorithm for right-to-left Arabic text mixed with left-to-right text)
> is working on the problem of shifting between horizontal and vertical in
> the rendering of CJKV (Chinese/Japanese/Korean/Vietname) ideographs.
> They like hard problems...
>
> >
> > -Carl
> >
> >------------------------------------------------------------------------
>
>
>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4595
-- Free e-mail group hosting at http://www.eGroups.com/