Subject: RE: PaceReformedContent3

From: "Bob Wyman" <[email-masked]>
Date: Sat, 2 Oct 2004 21:32:05 -0400

Dare Obasanjo wrote:
> Quite frankly I think embedding XML directly in atom:content is 
> a non-scenario mostly introduced by geeks on this list than 
> something that most publishers or content producers intend to do. 
	I guess I must be a geek... I'm definitely "on this list"... But,
I'm also a publisher... 
	Please see: 
http://www.imc.org/atom-syntax/mail-archive/msg10250.html
In which I provide an example of XML that we are embedding in atom:content
today. This works with Atom 0.3. How should I migrate this to Atom 1.0?

	Also, could you tell me how USGS should best migrate their existing
Earthquake RSS feeds to Atom? Currently, they just use a few namespaced
extension tags. But, instead of what they do today:
See: http://earthquake.usgs.gov/recenteqsww/eqs1day-M2.5.xml
it would be real nice if they could just insert one of the XML objects they
normally produce directly in an Atom file. i.e. What I'd like to see is:

<entry>
  <modified>2004-10-02:T19:18:43-0400</modified>
  <issued>2004-10-02:T19:18:43-0400</issued>
  <id>tag:example.com,2004:51147717</id>
  <content type="text/xml">
    <event id="51147717" network-code="NC" 
        time-stamp="2004/09/26_01:32:33" version="1">
     <param name="year" value="2004" /> 
     <param name="month" value="09" /> 
     <param name="day" value="26" /> 
     <param name="hour" value="01" /> 
     <param name="minute" value="30" /> 
     <param name="second" value="03.2" /> 
     <param name="latitude" value="37.4413" /> 
     <param name="longitude" value="-118.8762" /> 
     <param name="depth" value="6.0" /> 
     <param name="magnitude" value="2.1" /> 
     <param name="num-stations" value="38" /> 
     <param name="num-phases" value="38" /> 
     <param name="dist-first-station" value="14.0" /> 
     <param name="rms-error" value="0.05" /> 
     <param name="hor-error" value="0.2" /> 
     <param name="ver-error" value="1.0" /> 
     <param name="azimuthal-gap" value="39" /> 
     <param name="magnitude-type" value="D" /> 
     <param name="magnitude-type-ext" 
         value="Mcd = coda duration magnitude" /> 
     <param name="location-method" value="L" /> 
     <param name="location-method-ext" value="Local" /> 
    </event>
  </content>
</entry>

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 3 Oct 2004 15:45:49 -0400

Dare Obasanjo wrote:
> So do you really think I'm going to implement support for
> executing arbitrary code due to directives in an RSS/Atom feed? 
> Thanks but no thanks. I paid attention during Security
> month at Microsoft 2.5 years ago. 
	LOL! It's cute to see someone from Microsoft try to lecture me on
this subject when I generated much ill-will at Microsoft almost 13 years ago
by warning them about precisely the issue of passing procedural code in
their email and office systems. (Note: This issue was well-known to us as
far back as 1981 when we were building ALL-IN-1, the office automation
system that I was responsible for at Digital and which, along with Lotus
Notes, -- whose predecessor NewNotes, I had built -- was the model for
Microsoft Office and Microsoft Applications programmability in general.)
	In any case, I think you're overreacting. Absent bugs in the code,
XSL Templates can be considered safe as long as you don't permit external
functions to be called. A key idea behind much of what we've been doing the
last couple decades has been the separation of the presentation of objects
from their on-the-wire encoding. XSL Templates, CSS Style sheets, etc. are
all part of that effort and those of us who pay attention, and have been
paying attention, know how to handle them safely.
	In any case, any aggregator which is incapable or unwilling to
process XSL Templates should simply ignore content that requires that the
things be used. Users will find the tools that address their needs best --
and safely.

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 3 Oct 2004 08:49:59 -0700 (PDT)

--- Bob Wyman <[email-masked]> wrote:

> > What exactly do you expect aggregators like
> Bloglines, RSS Bandit
> > or Newsgator to do with some random XML content?
> 	At least with our "Atom over XMPP PubSub" service,
> we will be
> providing sets of XSL Templates as part of the
> metadata for the feed. Thus,
> aggregators that find data with unknown xml types in
> them will also be
> provided with the XML Templates needed to convert
> those types to
> representations more useful to them. (i.e.
> conversion to XHTML, etc.)

So do you really think I'm going to implement support
for executing arbitrary code due to directives in an
RSS/Atom feed? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: "Roger B." <[email-masked]>
Date: Sun, 3 Oct 2004 01:48:42 -0500

> <entry>
>     <id>...</id>
>     <content type="text/plain">blah blah blah</content>
>     <content type="text/xml"><blah /></content>
> </entry>

Eric: +1. 

In my case, if I don't see text/html or application/xhtml+xml, I
currently grab the content element's text node and run with it... in
an embedded XML scenario, that means I may end up displaying a
(mostly) empty entry, but nothing will catch fire.

If the publisher can live with that, so can I.

--
Roger Benningfield
http://admin.support.journurl.com/

---

From: Eric Scheid <[email-masked]>
Date: Sun, 03 Oct 2004 15:51:40 +1000

On 3/10/04 3:26 PM, "Dare Obasanjo" <[email-masked]> wrote:

> http://earthquake.usgs.gov/recenteqsww/eqs1day-M2.5.xml
>> normally produce directly in an Atom file.
> 
> Why would this be "nice"? What exactly do you expect
> aggregators like Bloglines, RSS Bandit or Newsgator to
> do with some random XML content? At least with
> namespaced extension elements they can be ignored by
> aggregators unaware of how to process elements from
> that namespace and human readable alternatives can be
> provided in  atom:content.
> 

where would you put the name spaced elements?

would the following work...

<entry>
    <id>...</id>

thus you have one content element which most general-reader aggregators can
handle, and you have xml content which a specialist aggregator can pick up
on.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 2 Oct 2004 22:26:37 -0700 (PDT)

> See:

=====

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 3 Oct 2004 02:34:21 -0400

Eric Scheid wrote:
> thus you have one content element which most general-reader
> aggregators can handle, and you have xml content which a
> specialist aggregator can pick up on.
	I would argue against this solution for two reasons:
	1. Requiring that data be duplicated for the benefit of
non-"specialist" applications could be a serious burden. In many cases, the
size of entries can be substantial. Also, it is likely that in many cases,
the specialist data would only be of interest to specialist applications.
Thus, it would be a pity to require conversion to accommodate non-existent
non-specialist readers. Not all aggregators will be interested in reading
all files...
	2. This increases the complexity of the by providing for alternative
content elements. I'm not sure *this* is *the* good reason to introduce this
concept. There are all sorts of ways that alternative content elements could
be used and abused and the idea should have much more justification before
it is pursued.
	What we plan to do is provide access to XSL Templates that will
instruct readers how to convert the XML data to default representations like
XHTML. This will be done via node level metadata in our "Atom over XMPP
PubSub" implementations. My hope is that we'll be able to do the same in
Atom files.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 3 Oct 2004 02:24:50 -0400

Dare Obasanjo wrote:
> At least with namespaced extension elements they can be ignored
> by aggregators unaware of how to process elements from that
> namespace and human readable alternatives can be provided
> in  atom:content.
	Please accept my apologies for having provided incomplete examples.
Clearly, the namespaces need to be identified.

> What exactly do you expect aggregators like Bloglines, RSS Bandit
	At least with our "Atom over XMPP PubSub" service, we will be
providing sets of XSL Templates as part of the metadata for the feed. Thus,
aggregators that find data with unknown xml types in them will also be
provided with the XML Templates needed to convert those types to
representations more useful to them. (i.e. conversion to XHTML, etc.) My
hope is that we'll be able to define some element or elements in Atom files
that would allow us to link to the same templates. If there isn't a standard
mechanism for doing this, we would have to define something in our own
namespace.

> Why would this be "nice"?
	It is nice since it allows people to syndicate data that is
generated by non-blogging applications without having to do excessive and
potentially fragile conversions of data. This allows the existing
applications to leverage the syndication infrastructure most efficiently.
The alternatives, like hacking all sorts of extensions into XHTML, don't
seem to offer much of value.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Sun, 03 Oct 2004 00:19:23 -0700

> today. This works with Atom 0.3. How should I migrate this to Atom 1.0?

First, you should stop using text/xml, which is bad for a bunch of 
reasons.
Second, if this thing is going to be widely distributed, you should use 
a real media-type, "text/xml" is broken and "application/xml" is 
information-free.
Third, you should put your own non-atom stuff in a non-atom namespace 
(I see you acknowledged this in a separate message).

Given the above, what's the problem?  Most receiving software modules 
won't have any idea what to do with it, that's OK, and those that 
recognize it (either by namespace or media-type) will do whatever it is 
they do.  Again, what's the problem? -Tim

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 15:13:48 +0100

I'm increasingly gravitating towards (or back towards cf. RSS) only 
allowing plain text, html and xhtml in Atom v1.0 (or more accurately, 
Atom v1.0's content elements. Put what you like in extensions). Anyone 
with me?

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 08:14:56 -0700 (PDT)

> Atom v1.0's content elements. Put what you like in

Frankly I think that's still too much. You can get
away with just supporting HTML. The only real
difference between text and HTML to authoring tools
will be using &nbsp; and <br> for spaces and newlines
respectively. 

XHTML has always been a geek thing. There's basically
no reason to use XHTML on the Web and there is even
less of a reason to use it in syndication formats. The
only benefit of XHTML in syndication formats I've seen
claimed is so aggregators can run XPath queries over
content. As someone who had RSS Bandit convert all
HTML to XHTML in content for about a year, that
feature is overrated. 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 11:58:38 -0400

>>Atom v1.0's content elements. Put what you like in

I think the name <content> is the issue here, because people think "but 
my 'content' is this other XML format". Putting XML elements in the 
content element is a good thing, because it's totally clear that the 
aggregator does or doesn't support the focus of the entry.

> will be using &nbsp; and <br> for spaces and newlines

Do we really need to relive the </TAG> saga? We have the text mode so 
people don't have to think about XML-containing-escaped 
-SGML-containing-an-escaped-angle-bracket-- that's where bugs come from.

> no reason to use XHTML on the Web...

Of course it's a geek thing. Users should have to think about anything
other than the BOLD button if they don't want to. You might have a
higher opinion of XHTML if you had ever had to maintain a large website. 
I'll note that both Blogger and Typepad use the XHTML mode of Atom 0.3 
for editing by default. I'm guessing they had reasons for doing this 
other than standards geekery.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 09:09:34 -0700 (PDT)

> aggregator does or doesn't support the focus of the

Encouraging people to put inaccessible content with no
alternates in Atom seems like a very bad idea to me.
Even worse, is thinking this is OK because you can
link to executable code that tells the client how to
interpret the content (i.e. XSLT stylesheets). 
 
> -SGML-containing-an-escaped-angle-bracket-- that's

Wrong. The problem with Tim Bray's "</TAG>" post is
that in RSS it is ambiguous whether the content of a
<title> or <description> element is text or HTML. So
clients don't know whether to escape the text content
before passing it to the browser or not. Most clients
always escape the content in the case of <description>
and I believe Dave Winer updated the RSS spec to
indicate this. The behavior for the content of <title>
across aggregators is less consistent especially when
you factor in aggregators that try to strip markup
from titles. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 12:37:37 -0400

> interpret the content (i.e. XSLT stylesheets). 

The reason PaceReformedContent3 allows only a single <content> element, 
with textual titles and descriptions, is so that <link rel="alternate"> 
elements have sufficient granularity to point to accessible alternatives[0].

> Wrong. 

How is that "Wrong"? Why do you think we have the text mode?

> The problem with Tim Bray's "</TAG>" post is
> <title> or <description> element is text or HTML. 

That's one of the problems.

> So

Yep. Having a text mode is good way to let aggregators turn off their 
totally-justified angle bracket paranoia code. Otherwise, it's never 
going to happen, because people will make escaping mistakes, and then 
we'll be back to square one.

"When the world ends, the only things left will be cockroaches, rats, 
Keith Richards, and mangled text that has been escaped one-too-many or 
one-too-few times."[1]

I don't understand why a text mode is a problem for you, but I'm willing 
to do laps on this until I understand.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg09363.html
[1] http://blogs.law.harvard.edu/crimson1/discuss/msgReader$1714?mode=day

---

From: Antone Roundy <[email-masked]>
Date: Tue, 5 Oct 2004 10:45:27 -0600

> alternates in Atom seems like a very bad idea to me.
To me, limiting the content formats that Atom is allowed to carry is 
like limiting the languages Atom entries are allowed to be written in.  
We're not going to forbid Japanese feeds just because a lot of people 
can't read Japanese.  Those who can't read Japanese will just have to 
find feeds in some other language.  Likewise, those whose feed readers 
can't read application/foo+xml will just have to find other feeds to 
subscribe to.  Some people find it useful to publish and subscribe to 
feeds in Japanese.  Some people find it useful to publish and subscribe 
to feeds with application/foo+xml content.

There are only two cases I can think of where this could cause pain:

1) Aggregated feeds that occasionally contain content of some odd type. 
  Solution: the aggregator or feed reader could be configured to drop 
entries with content it doesn't understand, or to give the user the 
option of trying to open the content in some other application.

2) Feed reader authors are going to be asked to add support for 
additional formats.  I know it's hard to say no, but until enough 
people have asked for support for some rare format, "no" is the 
solution, and users should learn to live with it.  If it's important 
enough to them to switch to a feed reader that does support the format, 
then the developer who wrote the feed reader with that support deserves 
their business.

How painful either of those is going to be depends on how common it 
will be for people to use esoteric data types for their content.  My 
<i>guess</i> would be that the vast majority of feeds are going to 
stick to the core data types that they expect their audience to be able 
to read.  Only people with a real need for another data type, people 
who don't care whether people read their feeds, and people without a 
clue are going to risk losing most of their potential readership by 
using esoteric formats.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 09:49:56 -0700 (PDT)

> How is that "Wrong"? Why do you think we have the

Because the folks who drafted that part of the spec
aren't aggregator authors and thus did not understand
the problem. 
 
> That's one of the problems.

That is THE problem. Can you point out to what the
other problems are as you see it? 

> we'll be back to square one.

*sigh* 

If you only have HTML mode then aggregators simply
have one piece of code 

1.) escape the content of <title> and <content> then
send it to Web browser. 

Having text and HTML mode adds this completely
unnecessary layer of checking what type of content it
is then escaping as needed. I've written both pieces
of code in RSS Bandit for RSS & Atom and the having to
write the latter struck me as quite silly. 

> to do laps on this until I understand.

It isn't a problem to me. It strikes me as
unnecessary. I've already written the unnecessarily
convoluted code in RSS Bandit once and whatever this
WG decided will take about half an hour to implement
so it's not that big a deal to me either way. 

=====

---

From: James Aylett <[email-masked]>
Date: Tue, 5 Oct 2004 18:01:57 +0100

> interpret the content (i.e. XSLT stylesheets). 

I hope it's clear that between collaborating parties, having
'non-standard' content types ('inaccessible' to mainstream feed
readers) is not only not a problem, but should be explicitly allowed.

So the issue comes down to whether this should be actively discouraged
on the open internet, by the specification text. The reason I think
this is an unnecessary burden on the Atom process is that "open
internet" is difficult to define. (On the other hand, I'd be in favour
of strongly pointing out any alternate mechanism.)

Obviously I don't want to encourage a situation where blogging folk
regularly create Atom feeds which blog-happy feed readers can't
usefully display; neither, however, do I want to end up with an Atom
that I can't use to push machine-readable content around
easily. Forcing me to put in empty <atom:content/> elements and shove
my actual content in an extension namespace, simply because
<atom:content/> can only be text/HTML or whatever, will do that. And
then I'll probably look elsewhere but Atom, even if every other detail
of what I'm doing is perfectly aligned with Atom.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 05 Oct 2004 19:07:06 +0200

>alternates in Atom seems like a very bad idea to me.

Requiring the community to invent a new format almost identical to Atom
just because they want the Atom features for what you call "inaccessible
content" seems like a very bad idea, too. It is also not clear to me
what "inaccessible content" would be. My understanding is that some want
to use Atom for so-called "photo blogs" including GIF or JPEG images. Is
that "inaccessible content"? Would the content become "inaccessible" if
the format is SVG rather than JPEG in some more general purpose graphics
blog? Is it that XHTML 1.0 is "accessible" while XHTML 2.0 would be "in-
accessible"? Where do you draw the line here?

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 13:18:33 -0400

>>>that in RSS it is ambiguous whether the content of
>>
>>a
>>

Other XML experts seem to agree that escaping is error-prone and just 
generally sucks. I don't think we should force publishers to do it, 
especially to a format with poor fidelity like HTML. You've said it 
doesn't matter much to you, so I'm not sure why we're still arguing. 
Maybe we're not.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 10:25:58 -0700 (PDT)

> doesn't matter much to you, so I'm not sure why

Who are these "XML experts" and how many of them are
aggregator authors or blogging tool vendors? 

By using XML the Atom WG is already "forcing"
publishers to escape content since at the very least
they have to escape ampersands and less than signs in
text mode. 

Then there's html mode. Since Atom will have an HTML
mode, producers are again being "forced" [as you put
it] to escape content since all the angle brackets and
ampersands in the HTML will have to be escaped. 

The only content format that doesn't require escaping
is XHTML. But there's then the issue of ensuring the
Atom file has a reference to the XHTML DTD so the
XHTML entity definitions can be used as is or else
they'll have to be escaped or at least translated as
well. 

Basically all content modes "force" publishers to
escape content. What was your objection again? 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 18:24:50 +0100

Photo blogs do not require JPEG data to be carried in the content 
element, and in fact consensus swung to them not being carried in the 
XML at all some time ago.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 10:33:37 -0700 (PDT)

--- Bjoern Hoehrmann <[email-masked]> wrote:
> content" seems like a very bad idea, too.

*sigh* 

Go read http://www.w3.org/TR/2004/WD-WCAG20-20040730/ 

The issue is only having inaccessible content. 

> It is also
> not clear to me

Read the WAI page and hopefully it answers your
questions. A blind person using a traditional
speech-to-text application cannot utilize a feed that 
contains some custom XML format like SVG or is just a
JPEG with no alternate text.  

I'm saying not having alternate text seems like a bad
idea. You seem to be saying "screw the blind". 

=====

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 05 Oct 2004 19:36:22 +0200

>XML at all some time ago.

I do not see evidence of that consensus in PaceReformedContent3, quite
the opposite in fact, it includes an example on how to include GIFs in
Atom documents directly.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 13:50:18 -0400

> aggregator authors or blogging tool vendors? 

http://norman.walsh.name/2004/05/31/TimPlus

> What was your objection again? 

This is error-prone:

'<summary type="HTML">A lengthy discourse on do&amp;rsquo;s and 
don&amp;rsquo;t&amp;rsquo;s for the HTML &amp;lt;style> element</summary>'

Also, we've accepted that aggregator authors can strip markup at will, 
and there is little hope of consensus on a "white list". The way to 
ensure the best fidelity for information is use plain text if at all 
possible.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 10:55:04 -0700 (PDT)

> http://norman.walsh.name/2004/05/31/TimPlus

I've seen Norm's posts on the matter. I think they are
purist arguments from a person heavily invested in XML
standards and technologies. 

> ensure the best fidelity for information is use

So you are basically arguing against HTML mode? That's
a completely different argument then. My point was
that if you have HTML mode you don't need text node.
You seem to be arguing that HTML mode is evil. 

=====

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 18:54:25 +0100

> the opposite in fact, it includes an example on how to include GIFs in

That may well be because I'm arguing here that the functionality 
discussed in PRC3 is unnecessary, and goes against consensus elsewhere.

See:
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

And you'll find:
http://www.intertwingly.net/wiki/pie/PaceSimpleResourcePosting

was incorporated into the spec a long time ago. It removed the need for 
wrapping JPEGs in XML.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 14:05:00 -0400

> You seem to be arguing that HTML mode is evil. 

I understand that fancy presentation can be desirable or required for 
many types of communication, but it comes at the cost of reduced 
fidelity. Text mode allows publishers to opt for fidelity by reducing 
presentation variability.

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 05 Oct 2004 20:19:01 +0200

>JPEG with no alternate text.  

So what? Say there is a feed with automatically generated webcam images,
is your point that Atom should not allow such a feed because some people
might not be able to benefit from it ignoring all those who would? Or do
you have a proposal for good alternate text for these images?

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 19:38:18 +0100

> you have a proposal for good alternate text for these images?

Bjoern, you're missing the point here. The webcam feed (and every other 
example anyone's given) can still be done with a short piece of html 
that links to each image. I can't imagine anyone would put a load of 
base64'ed JPEGs in their feed, even if we give them the option.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Wed, 06 Oct 2004 04:25:33 +1000

> XML at all some time ago.

mainly due to bandwidth and encoding hassles ... but the new method of

    <content src="url/to/image.jpg" type="image/jpeg" />

sidesteps both those hassles, and re-opens the question.

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 06 Oct 2004 04:34:14 +1000

> You seem to be arguing that HTML mode is evil.

I've got at least one client that wants to push out a big stream of pure
text content. This text content has odd things in it like <MERP.ASX>,
paragraph breaks represented as a double pair of CR LF characters, and so
on. There is no styling of the text. Not even psuedo-styling. Their intended
audience only wants to read the plain text.

Why the heck should this publisher have to pay to convert all that content
into HTML, just because there is some other class of software applications
that display things using a html-widget?

e.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 14:52:56 -0400

> base64'ed JPEGs in their feed, even if we give them the option.

<item>
<title>daily source code october 5 2004</title>
<link>http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3</link>
<description>[elided]</description>
<guid>http://www.blognewsnetwork.com/members/0000001/2004/10/05.html#a6723</guid>
<pubDate>Tue, 05 Oct 2004 15:45:33 GMT</pubDate>
<enclosure 
url="http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3" 
length="34110194" type="audio/mpeg"/>
</item>

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 05 Oct 2004 11:53:31 -0700

> you have a proposal for good alternate text for these images?

There should be alternate text *required* for all non-textual objects.  
In this case, I suggest "Webcam image of <whatever it's pointing at>, 
as of YYYY/MM/DD:HH:MM" -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 11:59:49 -0700 (PDT)

> length="34110194" type="audio/mpeg"/>

This feed highlights the problem exactly. This feed is
useless to every aggregator that doesn't support
enclosures. On the other hand if there was a
<description> element that described the audio file
then linked to it this content would accessible to a
larger number of aggregators. 

The Channel 9 folks[0] used to have feeds with
enclosures and no descriptions but realized they were
shutting out a number of aggregators so began to have
both <description> and <enclosure> elements. 

[0] http://channel9.msdn.com 

=====

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 19:54:25 +0100

> sidesteps both those hassles, and re-opens the question.

The 3 different types of content (text or html, embedded files, remote 
files) are pretty much independent in terms of which we have. I don't 
think there's a compelling case for the middle one that justifies the 
endless discussion over how to actually do it. If anything, allowing 
remote files  pulls the rug from under embedded files.

Graham

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 19:58:19 +0100

> length="34110194" type="audio/mpeg"/>

Robert, today we're talking about embedding files in XML. How is this  
relevant?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 15:01:06 -0400

> Robert, today we're talking about embedding files in XML. How is this  

Oh, sorry. I thought today was dig up old arguments day :)

I thought you were advocating html instead of @src AND base64. I see my 
mistake now.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 15:09:39 -0400

Dare Obasanjo wrote:
> enclosures.

Well, I assume some sort of support for <content @src> would be required 
of an Atom implementation. Note that there is no "fetch at night" 
behavior expressed or implied.

While I think all the "podcasting" hoo-ha is just a fad, it does 
illustrate the fact that a direct reference to a media object with a 
textual summary can be extremely powerful.

In fact, I pulled down "The Gilmor Gang" directly from an RSS enclosure 
to my iPod and listened to it on the subway this morning. I realize this 
speaks volumes about my mental health.

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 05 Oct 2004 21:18:02 +0200

>as of YYYY/MM/DD:HH:MM" -Tim

That is a short description of the image, not alternate content. It
might help on-demand image loading and some search engine to get a
little more data, but it does not help blind people. It is also most
likely redundant as the same information would be available throug
feed level meta data and entry level date meta data or the entry title
if you prefer that. In that it is similar to what is essentially <img
alt="Cheney, Edwards to face off" ...><br><a ...>Cheney, Edwards to face
off</a> you will currently find on <http://edition.cnn.com/> which is
exactly not what makes the document more accessible, quite the opposite
in fact. http://www.w3.org/TR/2004/WD-xhtml2-20040722 features similar
great examples, e.g.

  <object 
      src="http://www.example.com/myclock.class"
      type="application/x-java-applet">
          <param name="height" value="40" valuetype="data" />
          <param name="width" value="40" valuetype="data" />
          This user agent cannot process a java applet.
  </object>

or

  <object src="http://www.example.com/foo.mp3" type="audio/mpeg">
     A really cool audio file. If you want to download and install 
     a plug-in to listen to this file, please go to 
     <a href="http://www.example.com">www.example.com</a>
  </object>

of which at least the latter makes some sort of sense as it makes the
content potentially more accessible to some people yet does not help
deaf people. Please refer to

  http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html#howlers

for more examples where thinking of alternate text in terms of short
descriptions does not make much sense.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 12:30:04 -0700 (PDT)

*sigh* 

This thread is taking to much effort to have to
explain every little thing and I have a lot of work to
do. So I'm done with it. 

The point is that if the aggregator doesn't support
the fancy tricks with rich media or the user is
handicapped [independent of whether the name of the
tag is <content> or <enclosure>] then the user is shut
out. 

Requiring that there is always a textual
representation ensures that there is always lowest
common denominator content.

=====

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 15:36:01 -0400

> explain every little thing and I have a lot of work to

You're the one explaining every little thing?

> tag is <content> or <enclosure>] then the user is shut

<link rel="alternate">.

We can't prevent people from making inaccessible content. We can specify 
the granularity of atom entries such that alternate content can be 
linked to.

> common denominator content.

Nonsense:

<content type="HTML">&lt;embed src="my.mp3"></content>

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 5 Oct 2004 12:25:27 -0700 (PDT)

> audience only wants to read the plain text.

Guess what? Since Atom is an XML syndication format
they are going to have to at least escape the '<' in
<MERP.ASX>. Since they are already escaping content
the question is then whether converting CRLF to <br>
is that more onerous. I'd say the answer is no. If you
disagree I'd be very curious as to what tools and
development platforms they are using that makes this
one additional task so difficult. 

> that display things using a html-widget?

Considering that every agregator that enjoys
significant use on the Web today displays syndication
content using an HTML widget I think the publisher is
being extremely short sighted and obtuse if they think
they are catering to non-HTML aware aggregators. 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 05 Oct 2004 21:48:30 +0200

On Tue, 5 Oct 2004 12:30:04 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> Requiring that there is always a textual representation ensures that
> there is always lowest common denominator content.

Indeed. Alternative, textual content should of course be required. Imho,  
at least.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 05 Oct 2004 22:44:51 +0200

>common denominator content.

That's like saying requiring that you always post here ensures that
there is always content on this list. Atom authors are, like you, busy
people and might find, like you, that creating specific content takes
too much effort or is too difficult or expensive for other reasons and
thus be done with their less accessible content, just like you are done
with this thread with horribly inaccessible (aka uncreated) content.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 05 Oct 2004 16:58:43 -0400

Bjoern Hoehrmann wrote:
> there is always content on this list. 

Whoa whoa whoa. I am frustrated by my debate with Dare right now, but 
let's not go this direction. I, and everyone else, should chill out and 
remember that we are all trying to find the best answer.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Wed, 06 Oct 2004 10:19:27 +1000

On 6/10/04 5:25 AM, "Dare Obasanjo" <[email-masked]> wrote:

> is that more onerous.

Guess what? Those are two different abstraction layers. Taking some object
in memory and serialising as XML is a different operation to converting the
text content to Russian (uhm, Japanese ... no wait ... you want HTML,
right?)

e.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 06 Oct 2004 17:17:03 +0900

>standards and technologies.

I still remember the comments from people from the IE team
at one of the WWW Conferences (it must have been 1996 or
1997) about all the problems with tag soup and that they
really regretted it, for many reasons. Those weren't purists,
those were very practical people who learned the hard way.
Also, that was way before XML was baked. So much for
digging out old arguments. I was only watching on the
sidelines at that point.

So in my opinion, the TEXT mode/type might go, the HTML
mode/type might go, but the XHTML mode/type, or something
equivalent, is what I really care about.

Regards,   Martin.

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 06 Oct 2004 17:16:22 +0300

>tag is <content> or <enclosure>] then the user is shut
Even for feeds that are not human-readable, but merely meant for 
transporting content from one place to another?

I just have this nagging fear that if we require this, many authors will 
just link to empty or useless representations to satisfy the syntax 
requirements or just ignore it altogether, producing broken feeds.  And 
the blind will be screwed in either case.  It's much like the "alt" 
attribute for <img> is being used these days - I can't count the <img 
alt="">:s I've seen...  It should be a VERY STRONG SHOULD, but not a MUST.

But in general I am not opposed to this.  If we want to be 
handicap-friendly at the expense of a bunch of potential problems, let's 
do it...

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 06 Oct 2004 17:25:03 +0300

> equivalent, is what I really care about.

I'm all +1 for PaceReformedContent3 as it's currently worded, actually.

*But* I'd like to point out that for mobile devices, XHTML is a really, 
really good thing.  You don't have that much capacity, CPU and 
memory-wise, so the less you need to do parsing guesses while waddling 
in a tag soup, the better.  Also, XHTML and CSS together do actually 
help when you're trying to make a web site that can be used both on 
small devices as well as big screens.  It ain't perfect yet (I doubt it 
ever will be), but you know... Once you have tried to find a bus time 
table on a 216x176 pixel screen from a web site that uses *solely* 
tables for layout, is "IE-optimized" and designed for screen sizes for 
at least 800x600, and it is raining horribly - you kinda learn to like 
those sites that have a minimalistic design for all the important stuff 
- or at least a CSS-based design so that you can read at least *something*.

I like XHTML.  I like it a lot.  Both as a user (because of the benefits 
it gives, though most users would not be aware of them), and as a developer.

/Janne

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 07 Oct 2004 00:09:21 +0200

On Wed, 06 Oct 2004 17:16:22 +0300, Janne Jalkanen  
<[email-masked]> wrote:

> requirements or just ignore it altogether, producing broken feeds. [...]
> It should be a VERY STRONG SHOULD, but not a MUST.

I support this. A strong SHOULD but not MUST on alternative, textual  
content.

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 7 Oct 2004 10:32:04 -0400

On Tue, 5 Oct 2004 08:14:56 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:
> away with just supporting HTML.

I think we've put up with your tripe long enough in this thread. 
Blogger, Typepad, Moveable Type, Wordpress... all of these tools
generate plain text content feeds by default.  Some have specific
fields for user-entered data, others auto-generate plain text in a
variety of ways ranging from passable to laughable.  Regardless, plain
text content is the single most popular use case for feeds.

> The only real

If you insist on obfuscating the distinction between text and HTML,
may I recommend an alternate syndication format?  There is one that I
believe would meet your requirements precisely.  It has several
mailing lists devoted to it, with more being created all the time. 
The rest of us on *this* mailing list have different requirements, and
we will continue to work towards creating a format that enables things
outside the narrow scope of your vision.

-- 
Cheers,
-Mark

---

From: Isofarro <[email-masked]>
Date: Thu, 07 Oct 2004 20:04:49 +0100

Janne Jalkanen wrote:

[Accessible alternatives]
> I just have this nagging fear that if we require this,  many 
> authors will just link to empty or useless representations to
> satisfy the syntax requirements or just ignore it altogether,
> producing broken feeds. And the blind will be screwed in
> either case.

Empty representations may be the correct alternative in a number
of instances. Useless representations is something else.

Reducing an accessible alternative from a must to a "really
really should" would create an unneccessarily bigger
barrier to access. It would give authors an excuse to ignore 
accessibility requirements instead of determining whether the 
content they provide does have accessible alternatives.

By not requiring accessible alternatives, the specification is
the tool that is screwing the blind. By requiring accessible
alternatives, the author - or the tool he has chosen - is the 
one screwing the blind.

> It's much like the "alt" attribute for <img> is being used 
> these days - I can't count the <img alt="">:s I've seen... It
> should be a VERY STRONG SHOULD, but not a MUST.

You say that (alt="") as if it is a bad thing. There are valid 
and correct uses for alt="". I see more problems with no alt
attribute at all.

An alt attribute on an image is mandatory according to the
current HTML specification. How is reducing the requirement of
an accessible alternative to a "SHOULD" going to be an 
improvement for the end-user?

Mike.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Oct 2004 15:59:38 -0400

Isofarro wrote:

> alternatives, the author - or the tool he has chosen - is the one 
> screwing the blind.

No, the author is always responsible.

PaceReformedContent3 provides a crystal-clear way of specifying 
accessible alternatives, the <link rel="alternate"> tag. Linking is 
granular enough because the title and summary must be text or (X)HTML, 
and there can be only one content element.

Here is a sample entry:

<entry>
...
<title>A Picture of My Trip To The Lake</title>
<content src="some.jpg" type="image/jpg" />
</entry>

What improvements do you suggest?

Robert Sayre

---

From: Robert Koberg <[email-masked]>
Date: Thu, 07 Oct 2004 13:20:22 -0700

Why is this date invalid:

2004-10-07T12:00:00

? And this date valid:

2004-10-07T12:00:00Z

I understand the w3 spec says it is so, but why?

It is easy enough to work around, but I don't understand what it adds.

thanks,
-Rob

---

From: Martin Duerst <[email-masked]>
Date: Fri, 08 Oct 2004 07:05:00 +0900

>It is easy enough to work around, but I don't understand what it adds.

The first does not have a timezone. So within a period of about 26 hours,
it's not clear what time exactly this denotes. The second has a timezone,
so it is a very precisely defined point in time, up to a second.
A day has 86400 seconds, so this is a difference in precision of about
five orders of magnitude.

More specifically, the later allows atom items to be ordered quite
precisely timewise, while the former would lead to a lot of confusion
by users if a tool claimed to have ordered the items timewise.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 08 Oct 2004 07:07:08 +0900

><content src="some.jpg" type="image/jpg" />

Hello Tim,

I suggest to use the above example instead of the bloody
example currently in the pace, maybe with the tweak of
writing "from My Trip" rather than "of My Trip".

Regards,    Martin.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Oct 2004 19:23:33 -0400

Tim Bray wrote:
> On Oct 7, 2004, at 12:59 PM, Robert Sayre wrote:
> 
> Huh?  ReformedContent3 doesn't talk about <link rel="alternate">, and 
> furthermore says that if you have <content src=""> you MUST have 
> <atom:summary>.  Which I thought was an acceptable accessability 
> framework. 

It is my understanding that, by itself, it may not be. A summary is not 
an adequate substitute for the content itself, but it is good practice 
to provide it. Complete accessibility success may not be possible[1].

PaceReformedContent3 works with <link rel="alternate"> because the 
relationship between the entry and the alternate resource is 
sufficiently granular [0]. IMHO, there is no need to conflate 
containment with accessibility, especially when the inaccessible content 
also requires a URI to be dereferenced.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg09363.html
[1] http://www.w3.org/TR/2004/WD-WCAG20-20040730/

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 8 Oct 2004 09:15:24 -0400

> It is easy enough to work around, but I don't understand what it adds.

The first timestamp lacks a zone.  Without that timezone it's not possible
to tell "when" that instant in time expresses.

Think of it this way, these are all exactly the same instant in time:

2004-10-08T02:00:00-0400
2004-10-07T23:00:00-0700
2004-10-07T06:00:00Z

That's 2am EDT on Friday in Washington, DC, 11pm on Thursday in California
and 6 in the morning UTC.

If you just left off the timezone you'd be unable to tell when and could end
up with 26 different guesses about it.  Was your time noon in California and
thus early evening in London?  Or noon in Tokyo and the middle of the night
in New York?

And don't get me started on date calculations when timezone shifts for
daylight savings are applied...

-Bill Kearney

---

From: Robert Koberg <[email-masked]>
Date: Fri, 08 Oct 2004 06:49:56 -0700

OK - thanks to all who responded. I had been thinking of my own needs 
where I only care if something is before or after a dateTime.

What is the best practice in the following situation: My webapp (online 
content management) consists of projects which consist of user/authors. 
Authors in the same project might be (are) in different timezones 
internationally. My servers are in the US central timezone and the 
webapp uses their dateTime for created, modified and published date.

Is it OK or deceptive to use the servers dateTime and simply append the 
'Z' (which is what I am currently doing)? In other words, does it matter 
which timezone you use, just so you use one? Should I make the effort 
(for newsfeeds) to add/subtract time from the US central timezone based 
on the project and/or author user's timezone?

What would you do?

thanks,
-Rob

---

From: "Roger B." <[email-masked]>
Date: Fri, 8 Oct 2004 09:24:04 -0500

> 'Z' (which is what I am currently doing)? 

Rob: Deceptive? Sure, since it *is* misleading. Okay? That depends...
are you comfortable with consumers of your data working with dates
that are misleading?

The biggest practical impact will come when entries from your feed are
blended with others in an aggregator. Your entries will sort into a
slot that's five or six hours off from where they should actually be.

> What would you do?

I switched to using UTC internally, because that was the easiest
approach for my existing code. YMMV.

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 8 Oct 2004 10:49:15 -0400

> where I only care if something is before or after a dateTime.

You say that now.  Wait until you've got a ton of stuff stacked up and need
to interop with other systems....

> webapp uses their dateTime for created, modified and published date.

Track default timezones for each author and normalize any input to a 'server
standard' timezone.  That way all input/output routines will have to operate
with the understanding that they're either always showing 'server time' or
take steps to localize it for the user.  Most portal tools do this already,
letting the user select their own timezone and adjusting all shown
timestamps to use it.

> 'Z' (which is what I am currently doing)?

Deceptive and wrong.  Don't do it.

> In other words, does it matter which timezone you use, just so
> you use one?

Decide what you're going to use internally and stick to it.  It's often most
useful to go with UTC as it's always the same regardless of seasonal shifts.
Be very careful about time calculations when seasonal shifts are involved.
4pm in the summer is not the same as 4pm in the winter when shift-spanning
intervals are involved.

> Should I make the effort (for newsfeeds) to add/subtract
> time from the US central timezone based

Decide on what timezone to use internally and stick with it.  As long as you
understand how well (or how poorly) your underlying tools handle timestamps
it's not too hard to do it right.  The difficulty lies in failing to grasp
whether or not your tools handle timestamps in the ways you expect.

-Bill Kearney

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 8 Oct 2004 07:45:18 -0700 (PDT)

> on the project and/or author user's timezone?

What matters is that you use the accurate time
including timezone information. Whether the timezone
is that of the server or the client machine making the
post isn't really that relevant. 

For example, it isn't that important if you say 7:42
AM PST or 14:42 as long as there is a correct time in
the feed that maps to the same instance in time as
when the post was made.  

=====

		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 8 Oct 2004 14:36:03 -0400

Dare Obasanjo wrote:
>*sigh* Go read http://www.w3.org/TR/2004/WD-WCAG20-20040730/ 
	These accessibility guidelines say: "Guideline 1.1 Provide text
alternatives for all non-text content." However, my personal opinion is that
these guidelines are terribly flawed and incomplete. If we had a sincere
interest in addressing accessibility needs, we would have another guideline
that said:

	Guideline 1.x Provide non-text alternatives for all text content.

	The problem is, of course, that text is not the best format for
addressing the needs of many of the people whose interests are supposedly
addressed by the accessibility guidelines. Forcing everything to text makes
sense to those of us who have well working ears, eyes, etc. But, it is less
than optimal for those who don't. If there was more non-text content
available on the web it would be more likely that we'd have folk investing
in devices and methods for generating non-visual or non-aural
representations of data for those who have accessibility issues.

		bob wyman

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 8 Oct 2004 15:08:54 -0400

On Fri, 8 Oct 2004 14:36:03 -0400, Bob Wyman <[email-masked]> wrote:
> these guidelines are terribly flawed and incomplete

That is well outside our charter.  If you are interested in suggesting
improvements to the accessibility guidelines, I suggest you join the
WAI and/or participate in their public mailing list.

> If we had a sincere

You mean like http://www.w3.org/TR/WCAG10-CORE-TECHS/#multimedia-equivalents ?

> addressed by the accessibility guidelines. 

Please tell me how http://www.idlewords.com/audio/manifesto.mp3 can be
made more accessible to deaf people than
http://www.idlewords.com/audio-manifesto.txt

> Forcing everything to text makes
> than optimal for those who don't.

This makes no sense at all.

-- 
Cheers,
-Mark

---

From: Isofarro <[email-masked]>
Date: Fri, 08 Oct 2004 20:16:41 +0100

Bob Wyman wrote:

> If we had a sincere interest in addressing 
> accessibility needs, we would have another guideline that 
> said:
> 

Checkpoint 14.2 [1]

> The problem is, of course, that text is not the best format 
> for addressing the needs of many of the people whose 
> interests are supposedly addressed by the accessibility 
> guidelines.

Textual equivalents to non-textual media benefits a large
section of disabled people - notably blind visitors and
partially sighted visitors. Yes, people suffering from dyslexia
and other comprehension/related related disabilities would
prefer an image based approach - for example peepo [2]

> If there was more non-text content available on the web it
> would be more likely that we'd have folk investing in devices
> and methods for generating non-visual or non-aural

Speech recognition is improving and slowly getting there - 
mainly due to IBM investing heavily into ViaVoice. Are images -> 
text or images -> sound even realistically possible? Let alone 
the context issues.

Mike.

[1] http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension
[2] http://www.peepo.com/

---

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 21:40:21 +0200

On Tue, 5 Oct 2004 11:59:49 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:

[sorry to butt in, but this is irresistible]

> both <description> and <enclosure> elements.

What you are talking about there is essentially partial understanding.
Some might call that pixie dust. If it was done in a more systematic
fashion, who knows what magic might result.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 13:03:46 +1000

> http://www.idlewords.com/audio-manifesto.txt

http://www.idlewords.com/aslan/manifesto.mov

deaf people often prefer visual communication by signing over reading text.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 8 Oct 2004 20:50:24 -0700 (PDT)

> signing over reading text.

So a deaf person would rather have someone describe my
blog postings to him as sign language than read it?
That doesn't sound right at all. 

=====

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 01:54:23 +1000

> thus early evening in London?  Or noon in Tokyo and the middle of the night

or you could use a different algorithm.

Tell me, what time is it when you start your ten second countdown to
shouting "Happy New Year" on December 31?

If I want to refer to that particular moment in time, it would be
2004-12-31T23:59:50. If I want to refer to when that moment in time occurs
here in Sydney it would be 2004-12-31T23:59:50+10:00. In London UK it would
be 2004-12-31T23:59:50+00:00. They all refer to the same conceptual moment,
but it just happens at different times around the world.

e.

---

From: Walter Underwood <[email-masked]>
Date: Thu, 14 Oct 2004 11:18:21 -0700

> That doesn't sound right at all.

Sorry for the late response on this one.

ASL (American Sign Language) is a different language than English.
Different grammar, different vocabulary. If you grew up learning
ASL with your (deaf) parents, English may be a second language.
An ASL version of an English posting is a translation, not a
transcription.

This is exactly the same as preferring the posting in your
native Spanish instead of your second-language English.

Also, "sign language" is a generic term for many different
languages, ASL, British Sign Language, French Sign Language,
and so on. Last I heard, the ISO language codes incorrectly
lump them all under "sgn". The latest info on that seems to
be here:

  http://www.evertype.com/standards/iso639/sgn.html

ASL is a really neat language. Learn it if you get the chance.
It is quite different from English. For example, you can maintain
many more pronouns by choosing spatial locations for concepts.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek