OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Where have the element types gone?

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS