Re: [whatwg] Proposal for enhancing postMessage

[Mark S. Miller]

Message 2 of 2, from
:


To be concrete about it, I am a member of the Caja team, which is building
an object-capability subset of JavaScript by translation to JavaScript.
Currently, Caja brings object-capabilities only to intra-frame programming,
but we'd like to extend to inter-frame, inter-worker, and distributed
programming as well. Caja derives for earlier work on E, a distributed
persistent object-capability programming language based on communicating
event loops with promises. We are currently discussing this concurrency
model on the serverjs list as a proposed concurrency model for server side
JavaScript.

What Caja does for JavaScript, Joe-E does for Java. Tyler Close's ref_send
API adapts E's distribution and concurrency model, and has Joe-E and Caja
compatible implementations <
http://waterken.sourceforge.net/javadoc/org/ref_send/package-summary.html> <
https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p>. Tyler's Waterken web
server implements ref_send for server side persistent Joe-E apps. So
ref_send currently works fine within a browser frame, between a browser
frame and a server, or between servers. For all the distributed cases, this
works by serializing data to JSON and translating capabilities (object
references) into URLs.

But a URL cannot be redeemed for an HTML5 MessagePort
or any other access to frame or worker within a browser. Were postMessage
generalized to allow a list of MessagePorts, the capability transmission
portion of ref_send would have a trivial and safe direct mapping onto
inter-frame messages. The only non-obvious part is how to map the promise
for the result of an asynchronous message. But the answer seems simple:
create another MessagePort pair to represent that promise, and send along
with the message the port to be used as the receive side of that pair. I
suspect that many other similar plans would also be enabled by this proposed
enhancement to postMessage.

Does this make sense? Does it violate some design constraints I might not
know? Is it a good idea?

[whatwg] Proposal for enhancing postMessage

[Mark S. Miller]

Posted first at public-html-comments, but that list seems silent. I
have received suggestions to repost here.

Message 1 of 2, from
:

Currently, HTML5's postMessage may transfer some amount of data in the
message, and up to one MessagePort as the port parameter. I propose that
postMessage be modified to allow an array of MessagePorts to be transferred.

A perspective which is becoming increasingly common, and which I share, is
to regard the browser as operating-system-like. pages and iframes are like
protection domains (processes). Origins are like accounts. Historically, the
browser had no designed means of allowing communication between iframes from
different accounts. However, neither did it succeed at isolating them, so
many kludges were invented (like SubSpace's use of fragments) for building
some kind of communications system by abusing the holes in the browser's
isolation. This demonstated a need for a well designed and supported
inter-domain communications system -- the moral equivalent of an OS's IPC
system.

Among OS architectures, the most elegant, flexible, and capable are the
object-capability micro-kernel architectures. (Full disclosure: The creator
of EROS and Coyotos was my thesis advisor.) These show that if you get the
IPC semantics right, most of the features that monolithic operating systems
bundle into their kernel can instead be provided by some processes as
services to other processes. Without compromising security, it should be
expressive. The IPC mechanism must transfer messages that carry information
as well as permissions.

The fundamental kind of permission to be transfered is the permission to
send messages to a particular process, in order to make use of the services
it provides. In HTML5, the corresponding reification of permission is the
MessagePort. MessagePorts also provide another virtue shared by some
object-capability OSes: A service can receive messages sent on different
ports, distinguish which one they were sent on, and thereby provide
different clients with different service. One port may only provide query
service while another also services update requests.

With the addition of the port parameter, an HTML5 postMessage carries
information and up to one permission. This is adequate, but only is the
unsatisfying way that fragment manipulation was adequate to transfer
information. Given only this primitive, one can build a protocol for
transfering a bundle of MessagePorts. But if it is not too late, it would be
better to support this directly.

A concrete use-case that should help motivate this proposal: Since the
communicating iframes are each a JavaScript program filled with JavaScript
objects, it would be convenient to express the inter-frame communication as
a remote object invocation protocol between objects in these different
frames. If object A in frame X holds and inter-frame reference to an object
B in frame Y, this can be implemented by creating a MessagePort pair
representing access to B. A actually holds a local reference to a BProxy in
frame X wrapping the sending port. When called by A, BProxy serializes the
invocation and sends the serialized form over the sending port. The incoming
message handler of frame Y knows that a message for B has been received --
because of the receive port it was received from -- unserializes the
message, and delivers the unserialized message to B.

All good so far. But what if one of the arguments of the message is a CProxy
representing A's access to object C in frame Z? Well, if there's only one,
BProxy can use postMessage's port directly. If there's more than one, then,
if we generalize postMessage to accept an array of ports, then we're still
happy. But what if an argument is a pass-by-copy structure containing other
ports? It turns out we're still happy with no extra mechanism. In
serializing the message, the data portion of the serialization can have
indexes into the port array portion. The key thing as that both are
transfered together as part of one serialization. This is precisely how
CapIDL  is implemented on
EROS, CapROS, and Coyotos.


--
   Cheers,
   --MarkM

Re: [whatwg]

[Charles McCathieNevile]

On Tue, 10 Mar 2009 18:03:37 +0100, David Singer  wrote:


At 3:22  +0100 10/03/09, Charles McCathieNevile wrote:
That format has some serious limitations for heavy metadata users. In  
particular for those who are producing information about historical  
objects, from British Parliamentary records to histories of  
pre-communist Russia or China to museum collections, the fact that it  
doesn't handle Julian dates is a big problem - albeit one that could be  
solved relatively simply in a couple of different ways.


The trouble is, that opens a large can of worms.  Once we step out of  
the Gregorian calendar, we'll get questions about various other calendar  
systems (e.g. Roman ab urbe condita  
, Byzantine Indiction  
cycles , and any number of other  
calendar systems from history and in current use).  Then, of course, are  
the systems with a different 'year' (e.g. lunar rather than solar).  And  
if we were to introduce a 'calendar system designator', we'd have to  
talk about how one converted/normalized.


I'd rather have the historical pages say "In the 4th year of the first  
Indiction cycle of the second reign of the Emperor Justinian called the  
golden-nosed, in the 3rd day following the nones of August, at the hour  
of dawn in the city of Chrysopolis" (and then they give the Gregorian  
translation, e.g. 6am on the 12th of August 707 CE).


Indeed. That's one of the ways it can be done. IMHO it meets a huge set of  
the possible use cases. And it has the sort of simplicity that tends to be  
the defining characteristic of the best of HTML5. (Well, parsing isn't  
simple and is clearly part of the best of, but I am sure you get my  
drift...)


The other issue is the one of precision - while you can name a single  
year, which will deal with a lot of use cases there are a lot left out  
because the precision required is a period. Ranges are included in  
8601, and making a range syntax that handled almost all the relevant  
use cases is pretty straightforward.


Adding a range construct to 8601, or having a range construct ourselves  
using 2 8601 dates, seems like something we could ask for or do.


Yep. Using a slash, as ISO 8601 does, strikes me as pretty simple and  
gives us compatibility.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

[whatwg] Coordinates and measurements in HTML5

[Andy Mabbett]

In message , I wrote:

>Another abuse of ABBR in microformats for coordinates:
>
>Great Barr
>
>Bruce and I agree that this could be resolved, and HTML5 usefully
>extended, by a “location" element:
>
>Great
>Barr
>
>Using the “schema" attribute shown above, for non-Gregorian dates, we
>can extend that for Martian, Lunar (and eventually other bodies):
>
>longitude="23.47297">Sea of Tranquility
>
>and for nonWGS84 coordinates, in a manner similar to that I described
>in my proposals to extend the related Geo microformat:



and in message , I wrote:

>a more widely-scoped "measurement" element, capable of taking, for
>example, values of "duration", "length", "mass", "temperature", etc.;
>and a value; and perhaps a schema (defaulting to SI), would perhaps be
>more useful. Use cases are microformats, plus translation, automated
>conversion, sorting, etc.

which might look like:

5cm
or:
1 inch



Those suggestions seem to have been lost, in the discussion of 

Any thoughts?

Bruce subsequently preferred  for the former, while on
reflection, I think  might be more appropriate, given that it's
derived from the "geo" property in vCard.


-- 
Andy Mabbett

[whatwg] Profiles in-the-wild (was: Microformats, WebApps 1.0 and UI widgets in browsers)

[Andy Mabbett]

In message , in February 2007, I
wrote:

>In message <8434a459-7c78-42f8-bef6-98e6f0a5d...@w3.org>, Karl Dubost
> writes
>
>>I think there is a possible win-win here. The Mozilla UI  widget could
>>be activated only when the right URI (profile attribute)  is really
>>here.
>
>What proportion of pages currently marked up with microformats use the
>"correct profile, and do so correctly?
>
>I've created  to
>collect examples.

In case anyone's searching the archives for that, it ended up at:



but hasn't been maintained.

-- 
Andy Mabbett

Re: [whatwg]

[Aryeh Gregor]

On Tue, Mar 10, 2009 at 3:48 PM, Andy Mabbett  wrote:
> How widely - compared to Julian dates - are those published, in the wild?
>
> You might be tending towards 'Reductio ad absurdum'.

There are definitely many non-Julian/Gregorian calendar systems used
in the wild.  Rarely in English, but often in other languages.  The
Jewish calendar is commonly used in Israel, for instance.  (The front
page of he.wikipedia.org has both "today in history", using the
Julian/Gregorian calendar; and "events in the Hebrew calendar", the
same thing using the Jewish calendar.)  As far as I'm aware, the
Muslim calendar is commonly used among the world's billion-plus
Muslims, and the Chinese calendar by the billion-plus Chinese.

And once you start with that, it pretty much goes without saying that
for the sake of internationalism you have to spec every calendar that
any group of 10,000 people anywhere in the world uses as long as
someone is willing to write it up and post to www-style enough.  Maybe
not the Roman calendar AUC (let alone consul-based year names!), but
there have got to be dozens that people could come up with that are in
common use somewhere.  This would almost certainly be a significant
burden to implement in the long run.

A much saner solution seems to be to say that HTML supports exactly
one type of calendar: in this case, proleptic Gregorian.  Authoring
tools can be used to convert from other formats to Gregorian.  This is
the approach already taken by every computing standard I can think of.
 One fixed format is used for transmission (usually either proleptic
Gregorian or Unix time).  HTTP is one example of a widely-used format
that does this already.

Re: [whatwg]

[Toby A Inkster]

This seems to provide a good use case for a couple of RDFa attributes:

http://dbpedia.org/resource/";
  datatype="d:Mesoamerican_Long_Count_calendar"
  content="12.19.16.2.18"
  >13 Etz'nab' 1 Kumk'u

Adopting RDFa in HTML5 not only gives us a technique for embedding  
RDF triples in HTML, but also gives us an attribute pair (datatype,  
content) which can be used for general purpose embedding of machine- 
readable equivalents to human-readable information.


The only precaution is that for any element which uses one or both of  
these attributes, if the element also contains a property attribute,  
then the content and datatype attributes must be used in an RDFa- 
compatible manner.


--
Toby A Inkster

Re: [whatwg]

[Andy Mabbett]

In message
<22c1222d0903091317i4dccafd0peb182de2ba008...@mail.gmail.com>, Tom
Duhamel  writes

>Julian for instance cannot give a precise date

In what way is "Henry VIII (28 June 1491 – 28 January 1547)" not
precise?

>Wikipedia is often mentioned as a use-case, but based on my own experience
>(I am not an historian or anything, so my use of Wikipedia for historical
>events is sporadic) they most usually convert Julian dates to the Gregorian
>calendar. Julius Caesar died in 14 BC, not 52 of the Julius era on the
>Julian calendar (or whatever date it would convert to).

The above dates are from Wikipedia.

>Gregorian calendar entered common use somewhere during the 15th century, I
>believe.

It was first proposed in 1582 but was not widely used until later:




>Dates in 16th, 17th, 18th, 19th and 20th centuries are very common.
>Dates before the 15th centurie are less common

I think there were still ~365 per year ;-)

>they are usually not precise
>(just 14th century, for example, as the exact year cannot be determined),
>but there are cases where the exact date is known. Julius Caesar is one
>instance where a precise date is known (for both his birth and death) and
>this is around 50 BC. I don't think there are many known precise date before
>that.

Thee are in some fields, for instance astronomy, when the exact times of
eclipses can be calculated; or the appearance of the night sky on a
given date can be determined.

>I would accept that dates before year 1 be not represented.

You have just represented one, in your preceding paragraph. Why should
an author not be able to do so on a web page?

-- 
Andy Mabbett

Re: [whatwg]

[Andy Mabbett]

In message <20090309215532.ga3...@stripey.com>, Smylers 
 writes



Tom Duhamel writes:


My opinion is that all the following dates are precise:
2009
2009-03
2009-03-09

The later is more precise, but the three are all precise in my
opinion.


Being precise means having a small granularity.  Obviously that's
subjective, but in many cases granularity of a year would be deemed
quite large.


I take it you're not a geologist? ;-)

If I wish to compare my earnings, or the average daily rainfall, or 
somesuch, for 2007 and 2008, then the four-figure "" value is as 
precise as it is possible to be; anything with higher granularity would 
introduce bogus precision.



There are numerous reason to use dates which are not very precise, but are
still precise nevertheless. I'm going to release the new version of my
current project in April but I cannot tell
as of now the exact day of the release.


Indeed, that's a reason to use an imprecise date in that paragraph of
text.  But it isn't apparently why that date needs to be marked up as
such; what consumers of the above HTML would do something useful with
it?


I again refer readers to the use-cases I posted recently - including 
searching, sorting and visual display.


--
Andy Mabbett

Re: [whatwg]

[Andy Mabbett]

In message , 
Jim O'Donnell  writes


This is already a solved problem in the Text Encoding Intiative  (TEI). 
The value of a date/time is encoded in the Gregorian calendar,  using 
ISO8601. The calendar attribute is used to indicate the  calendar of 
the original, written date enclosed in the tags.

eg. from the TEI docs for dates and times
Feb. 11, 1731.
I suggested that the calendar attribute be adopted in HTML5, as it 
would be useful to those of us who mark up historical texts in HTML.


That's one possible solution - better than none - but I do wonder why 
we'd force authors to manually convert dates, when we all have machines 
which can do that.



We can't change the author's original written dates


That's certainly true.

--
Andy Mabbett

Re: [whatwg]

[Andy Mabbett]

In message , David Singer 
 writes



At 3:22  +0100 10/03/09, Charles McCathieNevile wrote:
That format has some serious limitations for heavy metadata users. In 
particular for those who are producing information about historical 
objects, from British Parliamentary records to histories of 
pre-communist Russia or China to museum collections, the fact that it 
doesn't handle Julian dates is a big problem - albeit one that could 
be solved relatively simply in a couple of different ways.


The trouble is, that opens a large can of worms.


It may do. Does that mean we ignore the issue? Hope that somebody else 
will solve it?


More than one possible method of dealing with Julian dates has been 
proposed, and I'm sure that I'm not alone in being open to further 
ideas.


Once we step out of the Gregorian calendar, we'll get questions about 
various other calendar systems (e.g. Roman ab urbe condita 
, Byzantine Indiction 
cycles , and any number of 
other calendar systems from history and in current use).  Then, of 
course, are the systems with a different 'year' (e.g. lunar rather than 
solar). And if we were to introduce a 'calendar system designator', 
we'd have to talk about how one converted/normalized.


How widely - compared to Julian dates - are those published, in the 
wild?


You might be tending towards 'Reductio ad absurdum'.

--
Andy Mabbett

Re: [whatwg] Historic dates in HTML5

[Andy Mabbett]

In message <49b58c3d.5000...@lachy.id.au>, Lachlan Hunt
 writes

>Bruce Lawson quoted Andy Mabbat:

Mabbett; as below.

>> Andy Mabbett has already listed use cases
>>
>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639
.html
>> ...
>> They can be mapped visually on a "SIMILE"
>>
>>   
>>
>> or similar time-line.
>
>It's not clear how such a timeline would make use of the time element
>and I couldn't find any use of microformats on that page.  Could you
>please elaborate on the relevance of that page in regards to this
>issue?

Neither of us claimed that that site is using microformats (though there
is no reason why it could not do so).

It was given as evidence that people are publishing historic,
non-Gregorian , BCE and low-granularity dates "in the wild"; and as a
use case for parsing sets of such dates found on other pages.

Furthermore, such timelines can be created from pages which publish
microformats (and which could thus use ).

An example of a tool to generate a SIMILE timeline from a page with
hCalendar microformats is:



and a simple timeline generated using that tool, by parsing the
microformats on:



is:




(aka  )


-- 
Andy Mabbett

Re: [whatwg] Persistent SharedWorkers

[Drew Wilson]

Thanks for the info - I wasn't aware of the new Ubuntu notification
infrastructure. Notes below:

On Mon, Mar 9, 2009 at 10:42 PM, Matthew Paul Thomas wrote:

>
> Speaking for Ubuntu, we are making active efforts to reduce the number
> of elements in the notification area (aka "system tray"), with the items
> remaining there being system-wide things rather than
> application-specific things. We would not be willing to let Web
> applications insert icons there. (Similarly, recent versions of
> Windows have been more aggressive about hiding notification area icons
> by default.)


This makes sense - one of my fears is that the system tray would end up
filled with a bunch of icons, which is information overload - this seems
like a good step to limit that.

One other alternative would be for the browser itself to have a single
system tray icon when it is running in the background, and clicking on this
icon would yield some way to view individual worker status via a menu or
other popup. Would this be an acceptable solution? If not, is there a
recommended way on Ubuntu for applications to maintain a visible footprint
on the system without keeping a window open?


>
> We also plan to make panel elements behave consistently as menus, rather
> than some being menus and others being buttons, so an onclick handler
> alone wouldn't work so well even if we allowed the icon.


This might argue in favor of the "single icon for the browser which pops up
status UI for workers" solution rather than individual icons per worker.


> >...
>
> Ubuntu 9.04 will feature initial work to ensure that notifications
> either pop up above other windows, or are interactive, but not both.
> (This is to avoid accidental clicks, and to allow interacting with
> whatever is under a popup notification without having to close it
> first.) Allowing arbitrary HTML in popup notifications would be
> basically incompatible with that. We would be happy to let Web pages
> show popup notifications using an icon and unstyled text, but not an
> onclick handler.


This is a good thing, as it's important for notifications not to
inappropriately steal input. However, it sounds like the API allows
displaying a notification, where no user interaction is possible (not even
"dismiss").

It seems like a very common use case is calendar notifications, where you
want to pop up one of these notifications, and provide two options for the
user: snooze and dismiss. Another example of a common notification would be
new mail notifications (ala Outlook), where a brief new email notification
is displayed, and the user has some way to click on it to view that email -
the notification spec describes this case, and suggests that the user would
click on "the envelope icon in the top panel".

So it seems like the two design goals ("applications can display
notifications, but the user can't interact with them") and ("we limit which
applications can display UI in the top panel") conflict, since the top panel
icon becomes the primary way that users respond to notifications?

After reviewing the spec (https://wiki.ubuntu.com/NotifyOSD) I see that
there are fairly strict design guidelines for notifications, so I agree that
arbitrary HTML is incompatible with Ubuntu display-only notifications.

I'm torn - I think that users on some platforms will expect to be able to
interact with notifications (it's a very common design pattern), so I don't
want to restrict the cross-platform functionality too much. But some
platforms fundamentally don't support interactable notifications (Palm's
webOS allows banner apps that contain only a single string of text, and I
don't think I'd be comfortable restricting the API to just that
lowest-common-denominator case). Perhaps the solution is for us to keep
interactable notifications in the API, but on Ubuntu those notifications
would be displayed within the browser window itself, with some change to the
browser's status bar icon to reflect pending notifications.

-atw

Re: [whatwg]

[Jim O'Donnell]

Hi David,

On 10 Mar 2009, at 17:03, David Singer wrote:



The trouble is, that opens a large can of worms.  Once we step out  
of the Gregorian calendar, we'll get questions about various other  
calendar systems (e.g. Roman ab urbe condita en.wikipedia.org/wiki/Ab_urbe_condita>, Byzantine Indiction cycles  
, and any number of other  
calendar systems from history and in current use).  Then, of  
course, are the systems with a different 'year' (e.g. lunar rather  
than solar).  And if we were to introduce a 'calendar system  
designator', we'd have to talk about how one converted/normalized.




This is already a solved problem in the Text Encoding Intiative  
(TEI). The value of a date/time is encoded in the Gregorian calendar,  
using ISO8601. The calendar attribute is used to indicate the  
calendar of the original, written date enclosed in the tags.

eg. from the TEI docs for dates and times
Feb. 11, 1731.
I suggested that the calendar attribute be adopted in HTML5, as it  
would be useful to those of us who mark up historical texts in HTML.  
We can't change the author's original written dates, but it would be  
useful to normalise documents using the Julian calendar to proleptic  
Gregorian dates.


See http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html and the  
associated guidelines on publishing dates and times

http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA



Adding a range construct to 8601, or having a range construct  
ourselves using 2 8601 dates, seems like something we could ask for  
or do.



8601 already allows ranges. Simply seperate two ISO8601 dates with  
a / eg. 1595-11/1596-02.


Regards
Jim

Jim O'Donnell
j...@eatyourgreens.org.uk
http://eatyourgreens.org.uk
http://flickr.com/photos/eatyourgreens
http://twitter.com/pekingspring

Re: [whatwg] URL encoding for XHR and Workers.

[Dmitry Titov]

Filed a bug on URL encoding,
https://bugzilla.mozilla.org/show_bug.cgi?id=482388

On Mon, Mar 9, 2009 at 5:02 PM, Jonas Sicking  wrote:

> On Fri, Mar 6, 2009 at 4:51 PM, Dmitry Titov  wrote:
> > Hi,
> > I have a couple of questions about Web Workers and text encoding of URLs.
> > Usually, 'server' and 'path' portions of URLs are always sent in UTRF-8,
> the
> > 'query' portion may be sent encoded if it contains non-ascii characters.
> I'm
> > looking at what should be an encoding used for this.
> > Lets say we have the Page that creates a Worker which uses includeScripts
> to
> > load the NestedScript.
> > Lets say the Page has some text encoding (from http header, meta tag or
> > otherwise). For example, in latest FF nightly (Minefield) the following
> > behaviors can be observed:
> > - XmlHttpRequest created on the Page would send its URL to server encoded
> > using UTF8, irrespective to the encoding of the Page. However, a
> > XmlHttpRequest created in the Worker would send the URL encoded using
> Page's
> > encoding. It seems that either XHR on the Page should also use Page's
> > encoding, or XHR in the Worker should use UTF-8. Bug?
>
> Sounds like it. Would be great if you could file a bug. That is why we
> have beta releases :)
>
> > - When a script of the Worker is decoded, the encoding of the Page is
> used,
> > unless Worker's script comes with http header overriding the ecncoding.
> That
> > sounds right. However, if the Worker in turn creates a nested Worker,
> uses
> > an XHR or importScripts(url), the URL encoding defaults back to the
> Page's,
> > even if there was overriding http header. It might be ok but seems a bit
> > illogical - the nested worker or imported scripts are 'sub resources',
> their
> > relative url is resolved against the Worker's base url, so it feels that
> > their default encoding should be inherited from Worker. Is it a bug?
>
> I suspect so yes.
>
> / Jonas
>

Re: [whatwg]

[David Singer]

At 3:22  +0100 10/03/09, Charles McCathieNevile wrote:
That format has some serious limitations for heavy metadata users. 
In particular for those who are producing information about 
historical objects, from British Parliamentary records to histories 
of pre-communist Russia or China to museum collections, the fact 
that it doesn't handle Julian dates is a big problem - albeit one 
that could be solved relatively simply in a couple of different ways.


The trouble is, that opens a large can of worms.  Once we step out of 
the Gregorian calendar, we'll get questions about various other 
calendar systems (e.g. Roman ab urbe condita 
, Byzantine Indiction 
cycles , and any number of 
other calendar systems from history and in current use).  Then, of 
course, are the systems with a different 'year' (e.g. lunar rather 
than solar).  And if we were to introduce a 'calendar system 
designator', we'd have to talk about how one converted/normalized.


I'd rather have the historical pages say "In the 4th year of the 
first Indiction cycle of the second reign of the Emperor Justinian 
called the golden-nosed, in the 3rd day following the nones of 
August, at the hour of dawn in the city of Chrysopolis" (and then 
they give the Gregorian translation, e.g. 6am on the 12th of August 
707 CE).




The other issue is the one of precision - while you can name a 
single year, which will deal with a lot of use cases there are a lot 
left out because the precision required is a period. Ranges are 
included in 8601, and making a range syntax that handled almost all 
the relevant use cases is pretty straightforward.


Adding a range construct to 8601, or having a range construct 
ourselves using 2 8601 dates, seems like something we could ask for 
or do.



--
David Singer
Multimedia Standards, Apple Inc.