[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Where have the element types gone?
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 ------------------------------------------------------------------------
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|