[
Lists Home |
Date Index |
Thread Index
]
On Tue, 2002-05-07 at 12:54, Jonathan Robie wrote:
> Then could you take some examples out of our specification or use case
> document and argue that people really don't need to do these things, and it
> is a mistake to define a language with this power?
Given that I'm objecting to the framework the specification defines,
which creates a particular view of XML without differentiating that view
from XML itself, you're (once again) asking the wrong question.
Is it a mistake to define a language with such powers? No.
Is it a mistake to call it XML query? Yes.
In a reply to Elliotte Harold, you said:
> But XQuery works directly on the XML, and does not require you to
> suck it up into some typed system. I don't know how to average your
> foo or sort it until you tell me its type.
That's where we diverge. You see the XML as typed. I don't, and
actively resist your insistence that the XML is typed and your williness
to generate pages and pages of specifications to support that view.
> You say you don't like types. Suppose that the user has a document that
> validates according to some schema. In that document, salary is a decimal:
>
> <person>
> <name>Jonathan Robie</name>
> <salary> 3.14 </salary>
> </person>
>
> <person>
> <name>Uche Ogbuji</name>
> <salary> 2341235.34 </salary>
> <person>
>
> The schema tells me that name is a string and salary is a decimal. The user
> created data using this schema, and the user knows full well that salary is
> a number and name is not.
>
> I would like the following query to succeed:
>
> avg( input()//person/salary )
>
> I would also like indexes to be able to make such queries fast, to enable
> appropriate sorting based on an index. I would like the following to be
> efficient:
>
> //person sortby (salary)
>
> That means that I want persistent systems to use the type information for
> indexing.
>
> I would like the following query to fail:
>
> avg( input()//person/name )
>
> I would like it to fail without forcing me to execute the query. That's
> what we call static typing. This query is simply wrong, and a query
> processor can know that.
You're welcome to do that for systems you build. I'm content to have it
fail at runtime, which is perfectly acceptable in systems where
developers do regular testing. The identifier "name" in the context
"person" is usually a tipoff that there shouldn't be a number in there.
Distinguishing which strings can be converted to numbers is not very
difficult. Dates are much more difficult, but I don't think anyone is
actually that fond of XML Schema dates and times.
Sorting and type systems have a complex set of relationships. I'd
prefer to have sorting work using mechanisms capable of much more
subtlety than XML Schema's type system permits.
> So far, when we have said things like this, you have responded with
> position statements - XML is a representation, and is not about philosophy.
> Don't you think that users have notions of types, and that users believe
> that salaries can be averaged but names can not?
I don't think teaching users that XML and Java have the same approach to
information is a useful thing - or something that will help them in the
long run. Yes, XML is alien to many programmers' vision of information.
The reconciliation you propose makes XML alien to many markup
developers' vision of information.
Are there more programmers with an interest in XML than markup
developers with an interest in XML? Today, sure. Will that last
forever? Dunno.
> Why is it wrong for XML
> processing to act in accordance with what most users will expect?
Depends on who the users are, and whether they have any actual interest
in XML.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
