msdemlei at ari.uni-heidelberg.de
Tue May 17 09:23:49 CEST 2016
On Mon, May 16, 2016 at 04:19:13PM +0100, Mark Taylor wrote:
> sec 3.3:
> The introductory text here says that the literal representations
> described are "as parameter values when invoking simple services,
> as data values in response documents (e.g. VOTable), etc.".
> However the text in 3.3. says values must be represented
> as described by the XSD standard. That's OK for name=value
> specifications (a la application/x-www-form-urlencoded),
> but not when the values are in a VOTable, since VOTable has
> its own rules about integer/floating-point/boolean value encoding,
> similar but not identical to XSD. The text should be adjusted
> to make clear that the XSD-alike prescriptions here don't apply
> to VOTable content.
> To confuse matters further ... by my reading of
> https://www.w3.org/TR/xmlschema11-2/ sec 126.96.36.199, one instance
> in which XSD representation of floating point values differs from
> that of VOTable is when it comes to infinities: it's "+Inf"/"-Inf"
> in VOTable but "+INF"/"-INF"/"INF" in XSD. That means that
> the examples in sec 3.3.4 would look different whether they
> are in name=value parameter specifications or a VOTable TD/PARAM.
> Actually as written they don't quite work for either: "Inf" is
> not legal in either case.
> Would it be easier to follow VOTable rules in all cases?
+1 from me for changing DALI to require VOTable literals throughout.
While it's not great that there are differences between VOTable and
XSD literals, I'm sure that we'll regret it far less to have an
inconsistency between DALI and XSD than between DALI and VOTable --
the latter have to play together far more often than the former.
More information about the dal