[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Where have the element types gone?

define non hard coded
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
>>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 

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'.)


> 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?


> -- Ron

See you in Orlando for XML 2001.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.