| Table of Contents | Prev | Next | Bottom |
|
Quick Table of Contents |
|---|
| 4 Datatypes 4.1 XML Schema Datatypes 4.2 XForms Datatypes 4.2.1 currency 4.2.2 monetary |
XForms includes all XML Schema datatypes, including the concepts of value space and lexical space, and all constraining facets, as specified in [XML Schema part 2]. For reference, these are
Built-in primitive types:
duration
dateTime
time
date
gYearMonth
gYear
gMonthDay
gDay
gMonth
string
boolean
base64Binary
hexBinary
float
decimal
double
anyURI
QName
NOTATION
Built-in derived types:
normalizedString
token
language
Name
NCName
ID
IDREF
IDREFS
ENTITY
ENTITIES
integer
nonPositiveInteger
negativeInteger
long
int
short
byte
nonNegativeInteger
unsignedLong
unsignedInt
unsignedShort
unsignedByte
positiveInteger
The Schema for XForms derives new types for all the above datatypes, placing no additional restrictions on the allowed value space, but including them in the XForms namespace.
One requirement is for XForms to include unique identifiers for each datatype listed here. We believe the facilities in XML Schema are sufficient for this, but welcome feedback on this issue.
There is concern that IEEE floating point, as used by the
datatypes xsd:float and xsd:double may be difficult or impossible
to implement on small devices. XPath (see 6 XPath Expressions in XForms) also uses IEEE representation
for numbers, and must be taken into consideration as to resolution of this conflict.
Several datatypes, namely xsd:QName,
xsd:NOTATION, xsd:Name, xsd:NCName, xsd:ID,
xsd:IDREF, xsd:IDREFS, xsd:ENTITY, and
xsd:ENTITES are highly specific to XML, and perhaps not as useful in XForms.
Particularly on small devices, the incremental cost of supporting these datatypes might be
excessive.
Fully implementing the pattern facet might be too
expensive on small devices.
Previous Working Drafts of XForms specified a mask
facet, with less implementation cost than the Schema pattern facet. What are
our options for adding an entirely new facet not defined in XML Schema?
The mask facet was defined as follows:
XML Schema has defined a Regular Expression language which
is "similar to the regular expression language used in the Perl Programming language",
and can be applied to most built-in datatypes. Regular expression syntax, however,
is considered complex by some. Therefore, XForms defines the concept of a mask
facet. All mask facets
are convertible into patterns.
XML schema
allows multiple pattern facets to be specified. Similarly, multiple
mask or pattern facets, but not a mixture, are permitted.
XForms mask uses the syntax and processing from [WML1.3]
format. Some examples:
A matches "A", "X", "$", "%",
or "."
a matches "a", "x", "$", "%",
or "."
X matches "A", "X", "$", "%",
".", or "4"
x matches "a", "x", "$", "%",
".", or "4"
N matches "0", "4", or "7"
3N matches "0", "63", or "999"
but not "1234" (Note: only allowed at end of mask)
*X matches "$", "3.0", or "ABCDEFG"
(Note: only allowed at end of mask)
\ causes the next literal character to be inserted into the
mask
NNN\-NNNN matches "123-4567" but not "1234567"
As with WML format processing, an XForms Processor must ignore
invalid masks.
Previous Working Drafts of XForms specified "dynamic facets"
that could be reevaluated at arbitrary times. One benefit of that approach was that a
now() expression could be used as a constraining facet on date/time datatypes.
What are our options for including similar functionality within the framework of XML Schema
datatypes?
The Schema for XForms derives the following types for use within forms:
The XForms datatype currency is derived from the XForms datatype
xform:string. A pattern facet with a value of [A-Z]{3}
is specified.
Valid currency values are specified in [ISO 4217].
Note:
Since new currencies may appear at any time, the currency values as defined in [ISO 4217] are not strictly enforced.
Examples:A value of 'Japanese Yen' would be represented as:
JPY
A value 'US Dollars' would be represented as:
USD
Forms often deal with monetary values. In many cases the currency type in use is well-known,
and not even needed in the instance data. When an explicit currency identifier is needed,
authors can freely use separate xform:decimal and xform:currency
values to accomplish this. For a unified approach, a monetary datatype would combine, in a single lexical space,
both a currency code and a decimal value.
Is such a datatype needed in XForms? If yes, how can it be defined in terms of XML Schema?
Examples: A value of 42 Indonesian Rupiahs would be represented as:
42IDR
A value of 4.37 Euro would be represented as:
4.37EUR
| Table of Contents | Top |