[
Lists Home |
Date Index |
Thread Index
]
From: "Mike Champion" <mc@xegesis.org>
Someone (S StL?, DO?) wrote
> >You don't care about data typing and XML while others do
> > and those are who XQuery is targetted at.
>
> Ahh, but that is the crux of the issue. Or at least to the extent that it
> is true that XQuery is targeted mainly at those who care about
> data types....
I don't think we should be backed into an argument predicated on one lot of people who care absolutely nothing about datatyping and another lot of people who do! Most developers would want an appropriate tradeoff between complexity and typing.
Mike mentioned hidden aspects, and I would like to suggest another.
In data comms, there are two classes of protocols: point-to-point
protocols and end-to-end protocols. Many layered systems end up
with a mix: the lower layers tend to be point-to-point and the
upper layer tends to be end-to-end; indeed, on of the reasons
for layered protocols is to allow different lower-layers: if I have
one kind of cable and you have another, we should not need to
have a gateway for our high-level protocols, just a gateway for
the lowest ones.
WXS people seem to be putting a view of schemas used end-to-end:
they describe all the constraints in a system and can be used
at any point along the way: document construction, GUI construction,
validation, type-augmented infosets, virtual interfaces to relational
databases, query type-checking.
But people who are building systems out of pipelines of parts which
probably already exist are working point-to-point. In a sense, they
only need to validate what the processors (gateways) in their pipeline do not handle themselves adequately: in that sense, they may need everything *except* the schema, because the schema is to a large extent hard-coded into their processors.
What kinds of things do people who are working more point-to-point
need? I think it tends to be quite simple structural constraints, various kinds of co-occurrence (of information items) constraints, and various kinds of business rules (e.g. constraints between values and structures.) Dare's comments that MS' #1 request concerning WXS is for co-occurrence constraints is interesting in this regard.
The shocking "poverty" (or, at least, the focus on structures and symbols) of DTD's datatypes makes sense, I think, when DTDs are viewed as a point-to-point tool. The application looks after datatyping.
Neither point-to-point constraints nor end-to-end schemas will go away. Both need appropriate technologies to support them. XML Schemas was developed biased towards support the end-to-end scenario (hence the pretence of universality) and Schematron (and perhaps RELAX NG) was developed biased towards to support the point-to-point use (hence the focus on validation and working with the XML infoset rather than superimposing something else on top.)
The TAI steamroller may not provide much value for people who are working with existing systems and whose concerns are point-to-point. Of course the TAI will provide enormous power, but for people who don't really need it, that power brings little value.
So how could XPath2/XQuery be presented that would make it more useful for people doing point-to-point work? I think the talk of "conformance levels" is the wrong way round: the baseline standard for XQuery should be for an XPath@/XQuery which has no TAI, just using casts and the XML Infoset, and no use of other schemas. Type-augmented XPath2/XQuery should be a separate, subsequent spec.
Type-augmented XPath2/XQuery could then have different conformance levels: the support of TAI or not is not an issue
of conformance as much as it is a fundamental architectural and
skills/manpower issue, because it entails buying into particular schema languages.
Cheers
Rick Jelliffe
|
