Tim Bray wrote:
On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML
/ Tim Bray [EMAIL PROTECTED] was heard to say:
| I tend to agree as well; in this case, the fact that this is an XML
| vocabulary is probably more relevant than the fact that it's an IETF
| RFC. So can we please have a Pace to call out to XSD? I'm pretty
Done. PaceDatesXSD
* Tim Bray wrote:
I tend to agree as well; in this case, the fact that this is an XML
vocabulary is probably more relevant than the fact that it's an IETF
RFC. So can we please have a Pace to call out to XSD? I'm pretty sure
that implementors would just use the libraries and The Right Thing
Julian Reschke wrote:
Risking that I sound like a broken report...: xsd:dateTime allows a
superset of what we can represent in RFC3339 (I'm talking about
semantics, not syntax here). So if we *don't* profile it, the spec will
need to explain how to obtain an ordering from a set of atom:updated
Robert Sayre wrote:
I would tend to agree. Can we have that regex go in the Pace itself?
That would make the proposal pretty much editorial, since the set of
allowed timestamps would be the same (right?).
As long as the set of allowed timestamps and their semantics is the
same, that's fine with
/ Robert Sayre [EMAIL PROTECTED] was heard to say:
| I would tend to agree. Can we have that regex go in the Pace itself?
The regex is in the pace.
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | Life is
Norman Walsh wrote:
/ Robert Sayre [EMAIL PROTECTED] was heard to say:
| I would tend to agree. Can we have that regex go in the Pace itself?
The regex is in the pace.
I took the liberty of adding it to the proposal section.
Robert Sayre
Having written the datetime support for Apache Axis (a
webservice implementation based on XSD schema and having
hosted a number of SOAP interop facilities, I am +1 on the
regular expression limitation, believe that all dates that
that conform to this limitation are valid RFC 3339 and
On 6/2/05 9:38 AM, Sam Ruby [EMAIL PROTECTED] wrote:
I am +1 on the regular expression limitation,
believe that all dates that that conform to this limitation are valid
RFC 3339 and xsd:dateTime values, and believe that it will interop with
all of the existing XSD implementations.
where
The 05 draft of the Atom format says:
3.3 Date Constructs
A Date construct is an element whose content MUST conform to the
date-time BNF rule in [RFC3339].
I'm actually using xsd:dateTime in the RELAX NG grammar and I went off
to look at RFC 3339 thinking I might write a
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2
Robert Sayre wrote:
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| Robert Sayre wrote:
[...]
| I agree. I was just writing a protocol implementation in Ruby On
| Rails (CRUDs very fast, btw). When I got to the part on date
| formats, I used xsd:dateTime code that was already done, figuring
| that's what
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
[...]
| So what do you do with something like
|
| 2005-02-04T17:20:00
Dunno.
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
values and MUST
Walter Underwood wrote:
--On February 4, 2005 11:18:17 AM -0500 Norman Walsh [EMAIL PROTECTED] wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date
Norman Walsh wrote:
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
17 matches
Mail list logo
