[oslc-core] Should we transition new specs to use dateTimeStamp instead of dateTime

[Arthur Ryman]

John,

I prefer making inclusion of TZ a Best Practice, AND providing clear 
guidance on how to behave if it's missing. This seems less likely to break 
existing implementations.

If we change the datatype it could result in breakage, e.g. in SPARQL 
queries. We'd also have to describe how implementations should behave when 
interacting with back level implementations, i.e. when they see 
xsd:dateTime, and the semantics of missing TZ. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational 

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
John Arwe <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
09/17/2012 02:07 PM
Subject:
Re: [oslc-core] Should we transition new specs to use dateTimeStamp 
instead of dateTime
Sent by:
oslc-core-bounces at open-services.net



> Rather than change the datatype, can't we simply require the use of TZ 
or 
> at least make it a best practice?

Could you?  Sure.  Should you? Distinct question. 
If you require it, not seeing why you would prefer to specify that 
incrementally (dateTime + requirement for time zone facet) rather than 
re-using the Schema-defined name that supplies the same semantic. 
If you don't require it (which is how I read Best Practice, perhaps not 
your intent) for *new* vocabulary, why are we willing to perpetuate a 
somewhat subtle bug in implementations?  Which scenarios does that 
help/enable? 
In short: why *notP [use the new datatype for NEW vocabulary]? 
Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net