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 <[email protected]> To: [email protected] Date: 09/17/2012 02:07 PM Subject: Re: [oslc-core] Should we transition new specs to use dateTimeStamp instead of dateTime Sent by: [email protected] > 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
