Subject: Atom Syndication Format To Draft Standard?

From: Robert Sayre <[email-masked]>
Date: Mon, 02 Oct 2006 03:01:32 -0400

I think we should move the format to Draft Standard by clearing up any 
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
in XHTML.

Thoughts?

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 02 Oct 2006 09:21:09 +0200

>errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 

I "think" that XHTML does not define an 'unicode-bidi' attribute.
Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: James M Snell <[email-masked]>
Date: Mon, 02 Oct 2006 00:35:54 -0700

> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined

Are you suggesting adding these to the common attributes or to Text
constructs and atom:content specifically?

- James

---

From: Eric Scheid <[email-masked]>
Date: Mon, 02 Oct 2006 17:23:28 +1000

> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined

add @attr where?

e.

---

From: Elliotte Harold <[email-masked]>
Date: Mon, 02 Oct 2006 10:31:13 -0400

> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 

Which elements would these be attached to?

Also, I'm not familiar with the unicode-bidi attribute. Do you have a 
reference for it? Which version of XHTML is that in? Do you mean the CSS 
unicode-bidi property?

-- 
Elliotte Rusty Harold  [email-masked]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

---

From: Robert Sayre <[email-masked]>
Date: Mon, 02 Oct 2006 11:17:17 -0400

> Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"?
Sure.

> Which elements would these be attached to? 

All of them.

Paul Hoffman wrote:
> At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
>> I think we should move the format to Draft Standard by clearing up 
>> any errata and adding two attributes: 'dir' and 'unicode-bidi', as 
>> defined in XHTML.
>
> We can't both add features and move to Draft Standard at the same time.

Dang, where'd that rule come from? It would probably be easier to add 
them in a separate document, huh?

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Oct 2006 07:37:12 -0700

>any errata and adding two attributes: 'dir' and 'unicode-bidi', as 

We can't both add features and move to Draft Standard at the same 
time. If we add features, we would recycle at Proposed Standard. 
Errata that are truly that and not technical changes can be made when 
moving to Draft Standard.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Oct 2006 08:52:56 -0700

At 11:17 AM -0400 10/2/06, Robert Sayre wrote:
>Dang, where'd that rule come from?

Probably RFC 2026, but if not there, it is certainly in the folklore 
of How Things Are Done.

>It would probably be easier to add them in a separate document, huh?

Maybe, but that would then confuse the issue by having two docs 
people would expect to have read in order to do the format. Given the 
very marginal value of Draft Standard, we should probably just revise 
and recycle at Proposed rather than split into two.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 2 Oct 2006 18:23:14 +0000 (UTC)

> Probably RFC 2026, but if not there, it is certainly in the folklore 

That's unfortunate. A documented process is a requirement for open standards
development, in the opinion of many

<http://blogs.sun.com/dennisding/resource/Open%20Standard%20Definition.pdf>

> and recycle at Proposed rather than split into two.

There is one mistake in the Relax NG (atom common attributes on author or
something) and at least one section that is somewhat unclear around the external
div in XHTML. 

The i18n attributes seem needed to display text without a guess based on
xml:lang.  Maybe we don't even need unicode-bidi. I don't think it would be
smart to take other features.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Oct 2006 21:06:50 +0200

Paul Hoffman schrieb:
> Probably RFC 2026, but if not there, it is certainly in the folklore of 
> How Things Are Done.
> ...

I thought this is possible if interop is demonstrated...

 > ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Oct 2006 21:10:16 +0200

Paul Hoffman schrieb:
> If we add features, we would recycle at Proposed Standard. Errata that 
> are truly that and not technical changes can be made when moving to 
> Draft Standard.
 > ...

Independantly of that, what do we do with all the normative references 
to proposed standards...:

Normative References:
REC-html401-19991224: [REC] ok
RFC4288: [BEST CURRENT PRACTICE] (-> BCP0013)
RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014)
RFC2822: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC2854: [INFORMATIONAL] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC3023: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC3066: [BEST CURRENT PRACTICE] obsoleted by RFC4646 RFC4647
RFC3339: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC3548: [INFORMATIONAL] -- intended standards level of DRAFT 
incompatible with this document's standard level!
RFC3986: [STANDARD] (-> STD0066)
RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT 
incompatible with this document's standard level!
REC-xml-20040204: [REC] ok
REC-xml-c14n-20010315: [REC] ok
REC-xml-exc-c14n-20020718: [REC] ok
REC-xml-infoset-20040204: [REC] ok
REC-xml-names-19990114: [REC] ok
REC-xmlbase-20010627: [REC] ok
REC-xmldsig-core-20020212: [REC] ok
REC-xmlenc-core-20021210: [REC] ok
REC-xhtml-modularization-20010410: document unknown

Informative References:
ISO.8601.1988: not checked
RELAX-NG: not checked
RFC2434: [BEST CURRENT PRACTICE] (-> BCP0026)
NOTE-datetime-19980827: document unknown
REC-xmlschema-2-20041028: [REC] ok

?

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Mon, 02 Oct 2006 12:19:31 -0700

I would definitely agree that having a dir attribute would be a good
thing. (would be even better if it were defined as xml:dir but...
whatever).

I'm not so sure about unicode-bidi.

- James

Robert Sayre wrote:
> [snip]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Oct 2006 12:27:25 -0700

>development, in the opinion of many

If it is a true requirement, then I guess the IETF is an abysmal 
failure. Oh, well.

OTOH, some folks in the IETF are trying to meet the desire by doing a 
better job of codifying what is and is not the process. Others, I 
must admit, are not trying at all.

>something) and at least one section that is somewhat unclear around 

I believe both of those would be considered clarifications, and thus 
not prevent the movement to Draft Standard.

>smart to take other features.

"needed to display" is often an issue the IETF ignores, so we might 
avoid it if the desire is to get to Draft Standard.

But Julian's second message needs to be dealt with first, and I 
assure you that many of those documents are not going to be going to 
Draft Standard any time soon (if ever) because there is no energy to 
test every required feature in the documents.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 02 Oct 2006 15:33:22 -0400

> If it is a true requirement, then I guess the IETF is an abysmal 

Well, openness is only one metric.

> But Julian's second message needs to be dealt with first, and I assure 
> you that many of those documents are not going to be going to Draft 
> Standard any time soon (if ever) because there is no energy to test 
> every required feature in the documents.

Well, I figured it might make sense to advance something that pretty 
much works. I now see how foolish that idea was. Cycling at proposed 
will be fine.

Robert Sayre

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Oct 2006 14:10:21 -0700

The Draft Standard requirement for demonstrated interoperability for  
all features is documented in RFC2026.  It's that requirement which  
leads to the popular conclusion that in many cases, adding a new  
feature is incompatible with moving to Draft Standard at the same  
time -- that popular conclusion is part of the folklore, not part of  
the requirements, which is appropriate.

You could draw a different conclusion and argue for that conclusion  
and might meet with some success, because determining sufficient  
"demonstrated  interoperability" is sometimes going to be a judgement  
call anyway.

Lisa

---

From: James M Snell <[email-masked]>
Date: Mon, 02 Oct 2006 16:20:01 -0700

I think the suggestion of adding a dir attribute is a very good idea.
The great thing is that it can be done without any significant backwards
compatibility concerns.  The definition of the attribute is simple enough:

  atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      attribute dir { "rtl" | "ltr" }?,
      undefinedAttribute*

The attribute establishes the base direction of the text content of an
element (and plain text attributes, e.g. category/@label) and is pretty
much identical in form to XHTML's dir attribute.

I'm not 100% certain, but we'd likely be better off limiting the
definition such that only "Language Sensitive" elements and attributes
are affected by the dir attribute.

In any case, +1 from me.

- James

---

From: David Powell <[email-masked]>
Date: Tue, 3 Oct 2006 01:55:31 +0100

>       attribute dir { "rtl" | "ltr" }?,

In the context of Atom, what's the problem with the Unicode bidi
control characters?

I suspect that browsers and standard OS text input widgets have better
support for Unicode bidi, than they do for a currently non-existing
Atom attribute.

Which elements would this help?

  content, subtitle, summary, rights and title support HTML, so this
  wouldn't be necessary for them.

  updated, published, logo, id, and icon I would guess can cope
  without.

  extensions are responsible for their own namespace, I don't think
  that we need to say what attributes can appear on an extension.

I think link@title, category@label, and person@name are the only
attributes that would really benefit.

Wouldn't Unicode bidi be more powerful than a single direction
element, that would restrict the field to a single direction?

As we depend on Unicode, then we can't really stop people from using
Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even
CSS bidi controls. I think we should think carefully before we
introduce yet another method for bidi text.  Especially one that will
be incompatible with all existing Atom consumers.

-- 
Dave

---

From: Karl Dubost <[email-masked]>
Date: Tue, 3 Oct 2006 10:03:38 +0900

> much identical in form to XHTML's dir attribute.

dir attribute in HTML.
http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2

Though in Unicode 5.0  which has been just published
[[[
In UAX #9, "Bidirectional Algorithm," for better interoperability,
the algorithm was modified to tighten up the conformance requirements
for using mirrored glyphs for characters. Higher level protocols are
discouraged, due to interoperability and security considerations. The
definition of directional run was changed to be the same as level
run, and the use of soft-hyphen with bidi text was clarified.
]]] -- Unicode 5.0.0
http://www.unicode.org/versions/Unicode5.0.0/
Tue, 29 Aug 2006 17:33:36 GMT

Maybe Martin or Richard can give us more information about it.

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

---

From: David Powell <[email-masked]>
Date: Tue, 3 Oct 2006 02:21:15 +0100

Tuesday, October 3, 2006, 1:55:31 AM, I wrote:

> introduce yet another method for bidi text.

Hmm, that sounded a bit odd. I don't want to "stop people from using
bidi"...

I was trying to say that implementations can support Unicode bidi and
HTML bidi today without any change to the spec, and that they seem
more powerful than an Atom bidi attribute.

-- 
Dave

---

From: James M Snell <[email-masked]>
Date: Mon, 02 Oct 2006 18:44:17 -0700

The challenge is not so much with (X)HTML as it is with the plain text
variants of content and Text constructs and with Language-Sensitive
attributes.  Currently, the bidi control characters are the only way to
establish the directionality in a content/@type="text" element.  Of
course, that works, but allowing a dir="rtl" attribute to specify a
default direction in the absence of an explicit RLO/RLE and PDF in the
text content makes life a bit easier for content publishers.

just to be clear, I'm saying the following would be equivalent (where
[RLO] and [PDF] represent the corresponding bidi controls)

<content type="text" dir="rtl">ABCDEFG</content>
<content type="text">[RLO]ABCDEFG[PDF]</content>

If the default direction for the entire document is RTL, allowing that
to be established at the feed or entry element level can save some
effort adding the appropriate controls to every text element.

- James

---

From: Martin Duerst <[email-masked]>
Date: Tue, 03 Oct 2006 14:20:08 +0900

At 04:10 06/10/03, Julian Reschke wrote:

>Independantly of that, what do we do with all the normative references to proposed standards...:

>RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level!

I've definitely thought about moving that a level forward, but that
may take another few months or so.

Regards,    Martin.

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

---

From: Eric Scheid <[email-masked]>
Date: Tue, 03 Oct 2006 12:03:50 +1000

> effort adding the appropriate controls to every text element.

so @dir is to be inherited by contained elements (similar to how xml:lang
and xml:base is)?

what happens with <content src=".." dir="rtl" /> ?

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 03 Oct 2006 12:03:50 +1000

e.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 03 Oct 2006 10:00:31 +0200

> what happens with <content src=".." dir="rtl" /> ?

The same as with <xht:object data="" dir="rtl"/> ... (Please don't ask the  
obvious question, it's probably not defined.)

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: "James Holderness" <[email-masked]>
Date: Tue, 3 Oct 2006 12:47:00 +0100

> <content type="text">[RLO]ABCDEFG[PDF]</content>

You should be aware that there is a significant difference between RTL 
override, RTL embedding and the RTL direction attribute in HTML.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 07:33:07 -0700

Doh! I actually meant [RLE] here and not [RLO].  Either way, yes, I know
there is a difference. The point I was trying to make is the same made
in HTML4-8.2:

    Although Unicode specifies special characters that deal with text
    direction, HTML offers higher-level markup constructs that do the
    same thing: the dir attribute (do not confuse with the DIR element)
    and the BDO element. Thus, to express a Hebrew quotation, it is more
    intuitive to write

    <Q lang="he" dir="rtl">...a Hebrew quotation...</Q>

    than the equivalent with Unicode references:

    &#x202B;&#x05F4;...a Hebrew quotation...&#x05F4;&#x202C;

- James

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 03 Oct 2006 16:29:57 +0200

On Tue, 03 Oct 2006 16:25:56 +0200, James M Snell <[email-masked]>  
wrote:
> A dir="rtl" on the content element establishes the base direction for
> the content but, just as with xml:lang, the content itself can override
> the value using whatever mechanisms are native to the content type.

xml:lang doesn't go to a child (embedded) document.

> Eric Scheid wrote:

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 07:25:56 -0700

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 08:03:02 -0700

huh?

REC-xml-2.12:

  The  language specified by  xml:lang applies to the element where
  it is specified  (including the values of its attributes), and to all
  elements in its content unless overridden with  another instance of
  xml:lang.

- James

Anne van Kesteren wrote:
> --Anne van Kesteren

---

From: "James Holderness" <[email-masked]>
Date: Tue, 3 Oct 2006 15:58:40 +0100

James M Snell wrote:
> there is a difference.

Ok, but I think you need to clarify what exactly it is that this attribute 
is supposed to mean then. Because if it's just the equivalent of wrapping 
the content in [RLE]...[PDF] it's essentially useless. If it's the 
equivalent of wrapping the content in <div dir="rtl">...</div> then I can 
see some value.

Regards
James

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 03 Oct 2006 17:13:51 +0200

>   elements in its content unless overridden with  another instance of

Your point being?

---

From: Robert Sayre <[email-masked]>
Date: Tue, 3 Oct 2006 08:42:22 -0700 (PDT)

> what happens with <content src=".." dir="rtl" /> ?

Nothing.

-Rob

---

From: Robert Sayre <[email-masked]>
Date: Tue, 3 Oct 2006 08:44:05 -0700 (PDT)

James Holderness wrote:
> is supposed to mean then. 

I'll take that action.

-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 09:01:29 -0700

Yes, equivalent to <div dir="rtl">

- James

James Holderness wrote:
> Ok, but I think you need to clarify what exactly it is that this
> attribute is supposed to mean then. Because if it's just the equivalent
> of wrapping the content in [RLE]...[PDF] it's essentially useless. If
> it's the equivalent of wrapping the content in <div dir="rtl">...</div>
> then I can see some value.
> 
> Regards
> James
> 
>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 04 Oct 2006 03:14:59 +1000

> elements in its content unless overridden with  another instance of

what happens here?

    <a href=".." dir="rtl"> .. yadda .. </a>

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 10:44:08 -0700

If I specify something like:

<content type="xhtml" dir="ltr">
  <div xmlns="...">
    This is some left-to-right text with a
    <a href="..." dir="rtl">right-to-left link</a>
  </div>
</content>

The behavior depends a large part on how the content is displayed.
Typically, I would expect the above to be equivalent to:

  <div dir="ltr">
    This is some left-to-right text with a
    <a href="..." dir="rtl">right-to-left link</a>
  </div>

However, in other contexts, depending on how the content is displayed,
it could be equivalent to something like

  <span dir="ltr">
    This is some left-to-right text with a
    <a href="..." dir="rtl">right-to-left link</a>
  </span>

Or even just

  &lrm;This is some left-to-right text with a
    <a href="..." dir="rtl">right-to-left link</a>&lrm;

Either way, the behavior of the dir on the anchor is unmodified and
standard (X)HTML rules apply.

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 04 Oct 2006 04:34:10 +1000

> standard (X)HTML rules apply.

so how might you code this:

    <p>here is some ltr text, with a link with
    <a href="..">rtl-text</a> which links to a
    document which is ltr-text</p>

I know the difference between @xml:lang and @hreflang ... so which is @dir
analogous to?

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 11:57:25 -0700

Nothing, there is no hreflang analog for dir, nor is there any pressing
need for such.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Oct 2006 12:48:06 -0700

This is sounding, smelling, and tasting like a rathole. Having fought 
the bidi wars in IDN, this doesn't surprise me. It's terribly 
difficult, and we don't have any good examples of formats or 
protocols that have gotten it right in a clean fashion. That's not to 
say we can't do it, just that we need to see a proposal with all the 
wording before we decide if it is right.

---

From: Bill de hOra <[email-masked]>
Date: Tue, 03 Oct 2006 23:56:58 +0100

> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 

"Foreign markup" is ambiguous.

[[[
Markup  from other vocabularies ("foreign markup") can be used in an 
Atom Document.
]]]

[[[
For the purposes of this  discussion, unrecognized markup from the Atom 
vocabulary will be  considered "foreign markup".
]]]

Perhaps this is what's intended by those statements:

"""
Markup not defined in this document is called "foreign markup"
"""

I don't think the document can forward to proposed without 
clarification. Also, "forward-compatible" is mentioned, but not defined 
- it's not possible to make a safe assumption on what it means, since 
it's relative to whatever "foreign markup" is. I assume "unrecognized" 
and "unknown" are synonymous.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 03 Oct 2006 19:58:42 -0400

Bill de hOra wrote:
> clarification. Also, "forward-compatible" is mentioned, but not 
> defined - it's not possible to make a safe assumption on what it 
> means, since it's relative to whatever "foreign markup" is. I assume 
> "unrecognized" and "unknown" are synonymous. 

None of these seem pressing to me. I agree that it's muddy, but I 
haven't seen any interoperability problems result. Have you?

-Rob

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 4 Oct 2006 02:59:02 +0200

> Markup not defined in this document is called "foreign markup"

No, I seem to remember pretty clearly from discussion that what
it means is thus:

    Markup not known to the consumer is called "foreign markup"

That is, extension markup the consumer knows to interpret is not
foreign markup. In contradistinction, Atom markup that the
consumer does not know to interpret *is* foreign markup (eg.
attributes from a hypothetical future version of Atom).

The document then sets forth how foreign markup should be
interpreted, ie. basically what the consumer should do on finding
things in a feed that it doesn't understand.

> defined - it's not possible to make a safe assumption on what
> it means, since it's relative to whatever "foreign markup" is.
> I assume "unrecognized" and "unknown" are synonymous.

I think given the above background you'll agree that the intent
of the document is pretty coherent. A clarification that makes
this background explicit would undoubtedly be helpful, though.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Bill de hOra <[email-masked]>
Date: Wed, 04 Oct 2006 02:40:26 +0100

A. Pagaltzis wrote:

> of the document is pretty coherent. 

I couldn't tell whether new Atom extensions are foreign markup, or 
something else to be dealt with under wrt being a "forward-compatible" 
friendly consumer. It's kind of circular. In short, I guessed and you 
told me I was wrong.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 03 Oct 2006 22:05:34 -0400

> friendly consumer. It's kind of circular. In short, I guessed and you 

Bill, please show us a bug? I don't think defining terms until we've got 
a good subset of an English dictionary
will make the format more interoperable.

-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 19:35:18 -0700

Yep, I'll work up a pace.

- James

Paul Hoffman wrote:
> the bidi wars in IDN, this doesn't surprise me. It's terribly difficult,
> and we don't have any good examples of formats or protocols that have
> gotten it right in a clean fashion. That's not to say we can't do it,
> just that we need to see a proposal with all the wording before we
> decide if it is right.
> 
>

---

From: Robert Sayre <[email-masked]>
Date: Tue, 03 Oct 2006 23:42:43 -0400

> Yep, I'll work up a pace.
I find this more than a little pushy.

I found the problem, I think I have an answer, I've already written the 
code, and I said I would deal with it earlier today:

<http://www.imc.org/atom-syntax/mail-archive/msg18874.html>

-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 21:00:28 -0700

> I find this more than a little pushy.

Cool!

> code, and I said I would deal with it earlier today:

Then write up a pace.  We can compare the two options and figure out the
best way to move forward.

Where's your code and how does it work?

- James

---

From: Robert Sayre <[email-masked]>
Date: Wed, 04 Oct 2006 00:44:29 -0400

>> I find this more than a little pushy.

???

> best way to move forward.

I am not sure what you are talking about.
 
-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 03 Oct 2006 22:12:05 -0700

> I am not sure what you are talking about.

You said: "I think I have an answer, I've already written the code, and
I said I would deal with it earlier today"

If that's the case, it would be great if you would provide a concrete
proposal that we can discuss or at least describe exactly what you're
looking for.  As Paul mentioned, this area is way too complicated to not
be talking in terms of concrete spec text.

- James

---

From: Robert Sayre <[email-masked]>
Date: Wed, 04 Oct 2006 01:32:23 -0400

James M Snell wrote:
> looking for.  

You seem to think I'm obligated to participate in a volumetocracy[1] in 
order to get my work done. I'm not, so there is no 'we'.

-Rob

[1] <http://www.franklinmint.fm/blog/archives/000873.html>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 4 Oct 2006 10:09:29 +0200

* Bill de hOra <[email-masked]> [2006-10-04 03:55]:
> A. Pagaltzis wrote:
> >I think given the above background you'll agree that the
> >intent of the document is pretty coherent. 
> 
> I couldn't tell whether new Atom extensions are foreign markup,
> or something else to be dealt with under wrt being
> a "forward-compatible" friendly consumer. It's kind of
> circular.

That’s what I meant. The intent is well thought-out and sharply
defined (in the mathematical sense), but it’s specification in
the document is not very explicit. It could stand to be clarified
a bit so that people don’t have to ask on the list to have
someone from the old boys club educate them before they know how
to read the spec.

Since you’re fresh from newly reading that section, how would it
have had to read in order to convey its meaning clearly?

* Robert Sayre <[email-masked]> [2006-10-04 04:20]:
> Bill, please show us a bug?

Bugs concerning forward compatibility are unlikely to surface
prior to Atom getting revised in some form. It’d be good if the
spec is clear enough that implementations have a chance to react
interoperably in the eventuality of such revisions.

It’s not some huge roadblocking issue, but neither is it without
merit. If it can be removed with an extra sentence in the spec
and a tweak to another and the opportunity is there, that seems
like a worthwhile small win to me. Polish shows in the details.

> I don't think defining terms until we've got a good subset of
> an English dictionary will make the format more interoperable.

Noone said anything about defining new terms.

Regards,

---

From: Henry Story <[email-masked]>
Date: Wed, 4 Oct 2006 13:51:41 +0200

The Atom Syntax group is discussing a bidi proposal (see end). I am  
not sure how much chance it has of getting through, and I don't  
understand the issues that well yet ( I have a few other things to do  
right now ), but I thought I should point out how I think it could  
impact AtomOwl.

In a recent thread in this group entitled "Making Content into  
Literals in AtomOWL", I was arguing for using literals more in the  
AtomOwl ontology.

Ie. I am suggesting that we convert

<entry>
          <title>Atom-Powered Robots Run Amok</title>
          ...
</entry>

into

[] a :Entry;
     :title "Atom-Powered Robots Run Amok"^^:text ;
     .

Literals in rdf don't have space for a bidi encoding. There is space  
for language encoding
such as "hello"@en^^:text but none for bidi.

I suppose this is not really a problem as one could always encode  
this in unicode when needed or for xml
fragments add it to a <div> in the content.

If it really were a problem, then that may constitute an argument for  
using a content object.

[] :title [ a :Content;
             :text "Atom-Powered Robots Run Amok";
             :bidi :rtl; ] .

Henry

Begin forwarded message:

> From: James M Snell <[email-masked]>
> Date: 3 October 2006 16:33:07 GMT+02:00
> To: James Holderness <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Atom and bidi
>
>