[
Lists Home |
Date Index |
Thread Index
]
Ronald Bourret wrote:
> 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.)
Yes, but (2) doesn't mean you can't use (3) as well (more below).
>>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.
Yes, I realize I wasn't clear.
If I write <lib:isbn>...</lib:isbn> I am using (2) but it doesn't mean
that an adequate datatype cannot be used to define the element
"lib:isbn" and that applications can't rely on this datatype to
implement (3).
If I write <foo:bar>...</foo:bar> with "foo:bar" having a datatype
"lib:isbn", I implement (3) in a pretty opaque way which makes it
impossible to use (2) any longer in a non "hard coded" way.
To me, by doing so you are removing most if not all the benefit of using
namespaces.
There are cases where this may be worth (for instance if you need to
restrict the definition of "lib:isbn" for your specific needs or if you
are writing a schema for an existing vocabulary which is already using
an element "foo:bar" to carry a "lib:isbn" datatype, but the decison
should be pondered.
> 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'.)
Sure.
> 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
> authoring.
Except that it's still a kind of dream. No API has been defined yet to
convey the information from the PSVI, XSLT 1.0 ignores it and SAX would
also need to be updated to do so. And also that it's not obvious that
schema should be processed each time a document is read...
Why should we want to pay this price in the cases were the added benefit
isn't obvious?
Eric
> -- Ron
--
See you in Orlando for XML 2001.
http://www.xmlconference.net/xmlusa/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
http://xsltunit.org http://4xt.org http://examplotron.org
------------------------------------------------------------------------
|
