[
Lists Home |
Date Index |
Thread Index
]
On Thu, 13 Oct 2005, Mail wrote:
> However, I don't think it is really that hard to extend XML further to
> make it strong typed. XML was initially designed without Namespace, and
> it is now patched with namespace and everyone is happy to accept it.
>
> Actually, XML can be patched in similar way to make it strong-typed.
> E.g. we can define a special XML attribute say xml:strong-typed = "yes" |
> "no"
> when the value is yes, then the "characters" in the quoted string of
> attribute or in <elmt>content</elmt> should be parsed with a set of
> well-defined syntax rules to reveal the types.
This still requires imposing one-size-fits-all lexical syntax for the
basic values. As people pointed out, WXS did this too, and is widely
disliked for that. I think the problem there was imposing an application-
or industry-level specification, when a generic extensible framework for
specifications of this kind was needed.
I think you idea of introducing datatypes as an add-on similar to
namespaces (or xml:ID) can be carried out by adding a bit more semantics
to the xsi:type attribute, and moving it from WXS to XML Core. An
important thing, I believe, would be to provide a framework for defining
datatype identifiers and declaring them on document nodes, but to leave
actual definitions of the datatype identifiers, lexical and semantic
spaces, outside the specification and in the hands of the users and
organized user groups.
E.g. here is an example of a document that conforms to the hypothetical
XML-with-datatypes:
<?xml version='1.0'?>
<order xmldt:currency="my:banks:currency:format"
xmldt:date="http://www.w3.org/2001/XMLSchema/date";
xmldt:text="http://www.standardsbody.org/xmld/1.0/pcdata";
>
<items>
<item>
<partNum xmldt="text">926-AA</partNum>
<productName>Baby Monitor</productName>
<quantity xmldt="int">1</quantity>
<USPrice xmldt="currency">39.98</USPrice>
<shipDate xmldt="date">1999-05-21</shipDate>
</item>
</items>
</order>
Comments:
[I try to use words "processor and "application" in the sense of XML Rec]
- The document above is XML-conformant.
- The xmldt attribute is reserved by the "Datatype definitions for XML"
specification.
- In the root element, xmldt binds datatype URIs to short names. The URIs,
as well as lexical and semantic spaces for values of the corresponding
datatypes, are defined by user groups, or just agreed upon between two
developers.
- On elements that carry datatype values, xmldt declares the datatype, by
referring to a short name.
- A conformant XML processor checks that all referenced types are
declared, and passes information about the type to the application
whenever a typed node is encountered.
Notes / Questions:
- It is possible for a conformant processor to pass the type information
to the application by returning a parsed semantic value instead its raw
lexical text -- according to the conventions established between the
processor and the application.
- Perhaps, xsi:type can be cleverly used instead of xmldt to achieve
compatibility with existing WXS-conformant documents.
- This offers datatypes only for elements, but not for attributes. Is
this a big disadvantage?
- Such a spec can (and should) be accompanied by a "standard library" spec
for a selection of datatype definitions deemed commonly useful. In the
worst case, this can be just WXS Part 2...
- A common scenario that I expect is when a development project
standardizes on a set of datatypes, and uses an off-the-shelf XML parser
that automatically maps text to values of an agreed-upon type in the
programming language, according to one of the off-the-shelf datatype
specifications.
- I suspect that the effect of this proposal can be achieved today via WXS
xsi:type or notations, but this would still require one to use schemas,
even in a project where the requirement is just to know datatypes at the
leaves, but process the tree structure dynamically. Is such a requirement
uncommon?
I'd be eager and grateful to hear why the any (all) of above is ridiculous
:-)
Vladimir
|
