Lists Home |
Date Index |
Eric van der Vlist wrote:
> Ronald Bourret wrote:
> > 1) Before we had namespaces, you made an assumption about the data type
> > of the element based on its name, which might not have been universal.
> > 2) After we had namespaces, and you chose to use them, you made an
> > assumption about the data type of the element based on its name, which
> > was "guaranteed" to be universal.
> > 3) After we had schemas (and simple and complex types), you can still do
> > (1) -- which is what you have done here -- or (2). You also have the
> > additional ability to query the data type at run time if the schema is
> > available.
> Yes, I was just complaining that people were usinf (3) without
> considering using (2) in cases where (3) doesn't bring added value.
A valid complaint. I would think (2) is sufficient for most people. (3)
is necessary for people writing generic, schema-driven apps. It is also
useful for people who feel it is safer in the long run to write
schema-driven code, even in apps that use a single schema. (The
advantage of such code is that you can often change the schema -- such
as changing a data type from int to long -- without changing the code.)
> More precisely in this case, if you are using (3) you can't use (2)
> -since the namespace which is used is different- any longer and your
> alternate solution is (1).
I'm not sure I understand this. Do you mean that if you base code
decisions at run time off of data types you (obviously) can't base them
off element type names? If so, I agree.
On the other hand, if you mean that the act of writing a schema you
can't base code decisions on element type names, then I disagree. You
clearly can -- you are simply hard-coding your schema into your
application. (I don't see what namespaces have to do with this. It's a
simply a question of recognizing element type name A in namespace A' or
data type name B in namespace B'.)
This is less awful than it sounds. It simplifies the application code in
some ways but still allows you to use the schema for validation and