Subject: [Ltru] default content

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Apr 2006 15:02:33 -0700

Hi -

As a technical contributor...

In section 3.3 of the proposed text at
http://www.inter-locale.com/ID/matching-diff-11-12.html,

| Each implementation MUST define the default content returned when no  
| tag matches the language priority list.  An implementation might, for  

The greater specificity is good, but...

(1) we should only be talking about what the result of the lookup
function is.  That result is NOT "content", but rather a language tag.
What content results from that tag selection is farbeyond our scope.

(2) do we really want to push the requirement for defining default
behaviour all the way down to implementations, rather than permitting
protocol specifications to do it as well?  I'd be happy with something
like "Applications, protocols, and specifications employing language
tag lookup MUST specify how the default language tag is determined."
I think this would be a reasonable balance between clarity and flexibility.

Randy

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

---

From: John Cowan <[email-masked]>
Date: Tue, 4 Apr 2006 18:09:18 -0400

> function is.  That result is NOT "content", but rather a language tag.

The first line of 3.3 says:

# Lookup is used to select the single language tag that best matches the
# language priority list for a given request and return the associated
# content.

Language throughout Section 3 is consistent with this: matching selects
one or more matching tags and returns the corresponding content.

Indeed, Section 1 speaks of

# several schemes for selecting or filtering sets of content by comparing
# the content's language tags to the user's preferences.

also emphasizing that it is content that is returned.

> I think this would be a reasonable balance between clarity and flexibility.

+1

-- 
John Cowan   <[email-masked]>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 4 Apr 2006 15:18:59 -0700

+1 to both parts.

My bad for implementing more "implementations" in the text.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: John Cowan [mailto:[email-masked]]
> Sent: 2006?4?4? 15:09
> To: Randy Presuhn
> Cc: [email-masked]
> Subject: Re: [Ltru] default content
> 
> Randy Presuhn scripsit:
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Apr 2006 15:54:13 -0700

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 04, 2006 3:09 PM

It should only talk about the tags.  Selection of content based on associated
language tags is just one possible application of language tag matching.
It is not the only one.  Getting rid of "and return the associated content"
is all I ask for.  Matching algorithms make for nice components, suitable
for wide reuse, whether as a specification or a library implementation.
"Match tag and return associated content" does not make a reusable
component, since what needs to be done to "return associated content"
will vary wildly depending on the application or protocol.
 
> also emphasizing that it is content that is returned.
...

Again, selection of content is only an example of a possible
use of language tag matching algorithms.  We shouldn't be talking
about content except when an illustrative example is necessary.

Randy

---

From: John Cowan <[email-masked]>
Date: Tue, 4 Apr 2006 20:38:12 -0400

> language tags is just one possible application of language tag matching.

I think that such a radical and pervasive change to the draft should not
be done now.

-- 
John Cowan      http://www.ccil.org/~cowan      [email-masked]
Be yourself.  Especially do not feign a working knowledge of RDF where
no such knowledge exists.  Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass.  --DeXiderata, Sean McGrath

---

From: Mark Davis <[email-masked]>
Date: Wed, 05 Apr 2006 10:52:28 -0700

I agree with Randy. Returning content is not the only purpose to 
matching, and even if returning content is the eventual goal, a 
particular process may only be concerned with the matching aspect; and 
leave it up to other processes to actually fetch content on that basis.

Mark