[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Objections to / uses of PSVI?
Guess I'll chime in here as well ... On Tue, 2002-05-14 at 18:46, Ronald Bourret wrote: > I am having trouble understanding two things in this entire discussion: > > 1) Why do people object so vociferously to the PSVI (other than the lack > of a catchy name and the fact that it came from an unpopular spec)? > > 2) How do PSVI proponents intend to use the PSVI? > > As far as I can tell, the PSVI contains three groups of information: > > 1) Additional data values (defaults). Since this already exists with > DTDs, it seems any controversy here should have existed before the PSVI > came to being. > > 2) Type information. My guess is that this is where the greatest > controversy / utility is. On the utility side, it means you can do > type-aware programming. On the controversy side, it means you can do > type-aware programming :) Well, it means you can do "type-aware" programming using the types of some other language than the one that you're programming in. The big advantage of type-aware programming, the b&d languages, is that they *enforce* types. Pass a long to a Java method that takes int without casting, and it won't even compile. You have to cast, which means that you have to think about why the parameter is typed int, but the value is long, and handle, in code, the cases when the value is of greater magnitude than the parameter. With XML Schema, you get to this a *lot*. Instead of types helping you not to make errors, they help you make more. Does your language differentiate between positiveInteger and nonNegativeInteger? No? What a pity! You have to. Does your language understand gHorribleKludge natively? Get on it, then. And on, and on. Most, even of the derived types, aren't defined by a faceting mechanism (although they could be, theoretically), and the faceting mechanism itself adds all sorts of interesting overhead. One specification, containing types for the document folks (ID, NMTOKEN), for the C-influenced folks (short, unsignedThisAndThat), for the database folks (gHorribleKludge). Apart from XML, no language on earth can natively type this stuff. Some languages don't bother with "primitive" types at all, and having them imposed with special rules (instead of: if you read the schema, it contains constraints on the lexical value space of any text appearing in this place, and if you don't read the schema you don't have to care, and if you don't do text-type-validation, you don't have to care either) is an enormous, easy to resent burden. Mind you, I'm in *favor* of strong typing; much as I admire Simon's or Uche's posts, I don't share their tastes in languages (well, I'm investigating Python, so point to Uche). But the result of introducing something as innocuous as unsigned integers of power-of-two-times-eight magnitudes makes my life in Java unpleasant (in a language without unsigned, how will you represent unsigned? Integer of next magnitude greater, with a little note (in your head or your code) that values less than zero are illegal, and greater than 2^x are as well? Use the signed version, and cope with the interesting mathematics that can result (watch out for promotions!)). I think that a better solution to the problem might also "follow the pattern" of RNG, embarrassing as it might be for W3C. First, split the Schema WG into the Types WG and the XML Structures WG. Types WG throws the door open to invited (preferably consistent) data type libraries, with a standard syntax and means of import into schemata. Have a minimal type library: string, number, boolean. Create a DTD profile (exact match, not DTD++--+-+alittleandatweak). Create a database profile to match what usually shows up as definitions in SQL (including SQL notions of date, which belong in SQL and languages that want to support it, but not in languages that emphatically don't). Create a scientific types library, with all sorts of incredibly arbitrary precision numbers. Use and takeup of the type libraries is likely to follow functional areas of programming (a fixed two-place decimal type will surely be popular in financial programming; it always has been, at least). It may still not match the language in use, but it will, at least, match the *problem* domain, and at that point, the type mismatch will be attributed to poor language design, not to poor design of types in schema. I'd like to see this, in fact. But the very definition implies that it's another type of augmentation of the instance. Not just valid, but type-valid, based on the contents of the type library (or libraries) referenced in the schema (or schemata). > 3) Validation information. Other than wasting space, my guess is that > virtually everybody will ignore this. It seems that the only people who > would be interested are a very small group of applications such as > validators and editors who want to tell the user where their document is > invalid. Not sure I agree here, either. The validation information may be the classic too-much-or-too-little. If it's invalid, does it tell me *why* it's invalid? Invalid per node-type, or invalid per complex-type? > Am I missing anything else here? I think so, but perhaps you won't agree at all. Amy! -- Amelia A. Lewis amyzing@t... alicorn@m... Songs and fame are vain endeavor-- only two things fail us never, only two things last forever-- sorrow and love, sorrow and love .... -- The Last Song of Sirit Byar This is a digitally signed message part
|
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
|