Re: Posted PaceLangSpecific

2005-02-17 Thread David Powell


>>The purpose of the Pace isn't to ensure that databases don't lose language 
>>tags:
>>it is to licence databases and other models to not preserve language tags 
>>where
>>they are not meaningful.

> Then, erm, why doesn't it say that?

I was tired.  Sorry for the confusion.

I will try to rephrase it later, unless the editors are OK with taking that on.

-- 
Dave



Re: Posted PaceLangSpecific

2005-02-16 Thread Graham

 
On Wednesday, February 16, 2005, at 03:03PM, David Powell <[EMAIL PROTECTED]> 
wrote:

>The purpose of the Pace isn't to ensure that databases don't lose language 
>tags:
>it is to licence databases and other models to not preserve language tags where
>they are not meaningful.

Then, erm, why doesn't it say that?

Graham



Re: Posted PaceLangSpecific

2005-02-16 Thread David Powell

Quoting Karl Dubost <[EMAIL PROTECTED]>:

> >>> Implementations MUST preserve the language context of language
> >>> sensitive constructs.

[...]

> If it's about stocking information in a database and that this
> information is not lost, I don't see how it's related to Atom. It's a
> separate design issue.


The purpose of the Pace is to define the set of "language sensitive constructs".
 The quoted sentence requires implementations to preserve the in-scope language
tag for those elements, with the implication that the language tag is not
significant for non-language-sensitive elements, and therefore need not be
preserved.

The purpose of the Pace isn't to ensure that databases don't lose language tags:
it is to licence databases and other models to not preserve language tags where
they are not meaningful.

Without this, the implication is that all elements are language sensitive.

--
Dave



Re: Posted PaceLangSpecific

2005-02-16 Thread Karl Dubost
Le 14 févr. 2005, à 23:19, Tim Bray a écrit :
On Feb 7, 2005, at 8:36 AM, Graham wrote:
On 7 Feb 2005, at 8:29 am, David Powell wrote:
Implementations MUST preserve the language context of language
sensitive constructs.
I have no idea what I'm being asked to do.
Equally mystified by that sentence. -Tim
Because maybe it's out of scope of Atom. :) David could maybe submit a 
test case to show what he meant.  It's why a defined class of products 
would be very useful here.

Implementations:
Atom consumers (readers, aggregators, …)
Atom producers? (xslt, scripts, human, …)
Atom parsers?   
If it's about stocking information in a database and that this 
information is not lost, I don't see how it's related to Atom. It's a 
separate design issue.


PGP.sig
Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=


Re: Posted PaceLangSpecific

2005-02-14 Thread Tim Bray

On Feb 7, 2005, at 8:36 AM, Graham wrote:
On 7 Feb 2005, at 8:29 am, David Powell wrote:
Implementations MUST preserve the language context of language
sensitive constructs.
I have no idea what I'm being asked to do.
Equally mystified by that sentence. -Tim


Re: Posted PaceLangSpecific

2005-02-07 Thread Robert Sayre
Graham wrote:
On 7 Feb 2005, at 8:29 am, David Powell wrote:
Implementations MUST preserve the language context of language
sensitive constructs.

I have no idea what I'm being asked to do.
That sentence should be dropped, since we never ask implementations to 
preserve anything. David is trying to change the text on xml:lang, so 
that it doesn't allow meaningless stuff like

...
Robert Sayre


Re: Posted PaceLangSpecific

2005-02-07 Thread Graham
On 7 Feb 2005, at 8:29 am, David Powell wrote:
Implementations MUST preserve the language context of language
sensitive constructs.
I have no idea what I'm being asked to do.
Graham


Re: Posted PaceLangSpecific

2005-02-07 Thread Martin Duerst
Hello David,
Many thanks for writing this up. I thought about writing it up
myself, but I'm glad I didn't start before I saw yours.
I haven't yet looked at the details, but I'm definitely +1 on
the general idea.
Regards,Martin.
At 17:29 05/02/07, David Powell wrote:
>
>I've posted PaceLangSpecific. It allows the use of xml:lang, but
>clarifies which properties are language specific.
>
>
>
>== Abstract ==
>
>Allow xml:lang anywhere, but restrict its effects to specific elements
>so that it is clear when implementations must preserve the language
>context.
>
>== Status ==
>
>Open
>
>Author: DavidPowell
>
>
>== Rationale ==
>
>xml:lang can appear anywhere and specifies a language for all children
>of its containing element. This is simple enough in the context of an
>XML document, but in the context of any other model, language tags
>need to be explicitly preserved for every property of each entry and
>feed.
>
>Many Atom implementations will use RDBMs or object-oriented
>implementations, rather than XML DOMs to model and store atom content
>internally. In a RDBMs model, each language sensitive field will
>require an extra database column. It is clear that some fields, such
>as atom:updated, are not language dependant, while others such as
>atom:content are. Some fields are grey areas.
>
>This proposal improves interoperability by ensuring that xml:lang is
>processed consistently by different implementations. It improves
>efficiency by allowing implementations to safely discard the language
>context for non-language specific fields.
>
>== Proposal ==
>
>In section 2, replace:
>
>{{{ Any element in an Atom Document MAY have an xml:lang attribute,
>whose content indicates the natural language of the element's content.
>Requirements regarding the content and interpretation of xml:lang are
>specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. }}}
>
>with:
>
>{{{ Any element in an Atom Document MAY have an xml:lang attribute,
>whose content sets the language content for the element and its
>children. The language context is only significant for the language
>sensitive constructs, which are indicated in this specification.
>Implementations MUST preserve the language context of language
>sensitive constructs. Requirements regarding the content and
>interpretation of xml:lang are specified in XML 1.0
>[W3C.REC-xml-20040204] Section 2.12. }}}
>
>In section 3.1, add the sentence:
>
>{{{ Except for the "type" attribute, the content of Text constructs is
>language sensitive. }}}
>
>In section 3.2.1, add the sentence:
>
>{{{ The content of atom:name is language sensitive. }}}
>
>In section 4.6.5, add the sentence:
>
>{{{ The content of the "title" attribute is language sensitive. }}}
>
>In section 4.13.3, add the sentence:
>
>{{{ The content of the "label" attribute is language sensitive. }}}
>
>In section 4.15, add the sentence:
>
>{{{ Except for the "type" and "src" attributes, the content of
>atom:content is language sensitive. }}}
>
>
>
>== Impacts ==
>
>Depending on which extension paces are accepted, a statement on the
>default language sensitivity of extension elements will need to be
>made.
>
>
>
>--
>Dave 



Posted PaceLangSpecific

2005-02-07 Thread David Powell

I've posted PaceLangSpecific. It allows the use of xml:lang, but
clarifies which properties are language specific.



== Abstract ==

Allow xml:lang anywhere, but restrict its effects to specific elements
so that it is clear when implementations must preserve the language
context.

== Status ==

Open

Author: DavidPowell


== Rationale ==

xml:lang can appear anywhere and specifies a language for all children
of its containing element. This is simple enough in the context of an
XML document, but in the context of any other model, language tags
need to be explicitly preserved for every property of each entry and
feed.

Many Atom implementations will use RDBMs or object-oriented
implementations, rather than XML DOMs to model and store atom content
internally. In a RDBMs model, each language sensitive field will
require an extra database column. It is clear that some fields, such
as atom:updated, are not language dependant, while others such as
atom:content are. Some fields are grey areas.

This proposal improves interoperability by ensuring that xml:lang is
processed consistently by different implementations. It improves
efficiency by allowing implementations to safely discard the language
context for non-language specific fields.

== Proposal ==

In section 2, replace:

{{{ Any element in an Atom Document MAY have an xml:lang attribute,
whose content indicates the natural language of the element's content.
Requirements regarding the content and interpretation of xml:lang are
specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. }}}

with:

{{{ Any element in an Atom Document MAY have an xml:lang attribute,
whose content sets the language content for the element and its
children. The language context is only significant for the language
sensitive constructs, which are indicated in this specification.
Implementations MUST preserve the language context of language
sensitive constructs. Requirements regarding the content and
interpretation of xml:lang are specified in XML 1.0
[W3C.REC-xml-20040204] Section 2.12. }}}

In section 3.1, add the sentence:

{{{ Except for the "type" attribute, the content of Text constructs is
language sensitive. }}}

In section 3.2.1, add the sentence:

{{{ The content of atom:name is language sensitive. }}}

In section 4.6.5, add the sentence:

{{{ The content of the "title" attribute is language sensitive. }}}

In section 4.13.3, add the sentence:

{{{ The content of the "label" attribute is language sensitive. }}}

In section 4.15, add the sentence:

{{{ Except for the "type" and "src" attributes, the content of
atom:content is language sensitive. }}}



== Impacts ==

Depending on which extension paces are accepted, a statement on the
default language sensitivity of extension elements will need to be
made.



-- 
Dave