Jeni
Thanks for such a quick response. I'll leave out my faux pas and cover those
things where I think some further discussion is needed.
> > In the definition of double I couldn't work out how the decimal
> > exponent was being mapped to an integer. Is there some special magic
> > in dt:default?
>
> Exponents must be integers. The regular expression for doubles doesn't
> allow anything else. This is in keeping with the WXS definition of
> doubles. See http://www.w3.org/TR/xmlschema-2/#double
The W3C spec is crap. It does say that exponents must be integers, and then
states clearly that 1267.43233E12 and 12.78e-2 are valid floats. One of
these statements must be wrong. The examples are closer to the standard form
of floating numbers, which allows decimals for mantissas. The spec clearly,
and confusingly, states "The representations for exponent and mantissa must
follow the lexical rules for integer and decimal." Our regular expressions
should reflect this. Note that the "canonicalized form" for floats is
required to have a decimal point, but the number after it must be 0. Whoever
invented this rubbish should be taken out and shot!!!
> > I was also confused by your definition of month, where I can have
> > any two digits in the value but when it comes to matching these we
> > somehow magically change a two digit string to a single digit
> > number, so that what you check for is $this.month = 1 not
> > $this.month="01". I get wary of any "automated casting" presumption.
> > We need to spell out the rules here very, very carefully.
>
> The casting rules used in XPath 1.0 are spelled out reasonably (!)
> carefully in the XPath 1.0 specification at
> http://www.w3.org/TR/xpath. These specify how XPath strings are cast
> to XPath numbers.
>
> You're right that we need to spell out how values of the datatypes
> defined in the datatype library are cast into the XPath datatypes. I
> suggest that the default behaviour is that the string value is used
> when converting to a string, and that this string value is converted
> to a number using the number() function and to a boolean using the
> boolean() function when XPath requires these conversions.
>
> To cater for times when this default casting isn't desired (e.g.
> boolean(xs:boolean('false')) should be false rather than true, and
> number(xs:double('1E1')) should be 10 rather than NaN), one
> possibility is to have the XPath datatypes built-in, named #string,
> #number and #boolean, and to enable people to specify how values are
> cast to these using the normal <map> methods. For example:
>
> <datatype name="boolean"
> ns="http://www.w3.org/2001/XMLSchema-datatypes">
> <parse name="value">
> <regex>(?[true]true|1)|(?[false]false|0)</regex>
> </parse>
> <property name="is-true" as="#boolean" select="$value/true" />
> <property name="is-false" as="#boolean" select="$value/false" />
>
> <map to="#string" select="$this" />
> <map from="#string" select="dt:if($this, 'true', 'false')" />
>
> <map to="#number" select="dt:if($this.is-true, 1, 0)" />
> <map from="#number" select="dt:if($this, '1', '0')" />
>
> <map to="#boolean" select="$this.is-true" />
> <map from="#boolean" select="dt:if($this, 'true', 'false')" />
> </datatype>
>
> What do you think?
Looks to me to be the right way to go.
> > I could also do with an explanation of what the <include
> > href="numbers.dtl"/> statement is doing.
>
> It's including a datatype library called numbers.dtl, namely the
> datatype library given in the first part of Appendix A. This is so
> that the datatype definitions in the date/time datatype library can
> use those types in the property definitions (for example).
Ah! Perhaps a comment referring to Appendix A would be useful for your less
observant readers, such as my humble self!
Martin
-- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Mon Aug 22 22:49:44 2005
This archive was generated by hypermail 2.1.8 : Mon Aug 22 2005 - 20:53:01 UTC