Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Interesting pair of comments (was Re:
 > > On 14 Jul 2005, at 05:02, Rick Jelliffe wrote: > >> "There appeared to be no obvious way to split the XML Schema >> specification >> into layers or sub-languages" >> >> So XML Schemas is such spaghetti that it cannot be untangled? Yikes. >> But I don't believe it. > > The difficulty in splitting the spec into layers or shells is that > there isn't consensus on which features are core and which are > esoteric. You're 80 is my 20 was order of the day and highlighted > in Paul Biron's summary of the experience reports. Err??, that quote came from you. If it not true now, please revise your report! (Otherwise it just joins the morass of FUD against any change.) (The purpose of the split that I mention was demonstrate that there is at least one way that the structures spec and XML schemas could be refactored. It isn't important whether it meets my 80 or your 80: all it needs to do to be plausible is to look like meeting *some* groups' 80.) >> One problem with a monolithic spec is that it gives little >> guidance about what is core and non-core. Everything is >> core. A more layered spec such as I suggest would clarify >> that, for example, mixed content is a core feature but xsi:nill >> is not. > > Which I think, proves my point. Whilst I agree that mixed content is > core - from my perspective it's what XML is all about, but for many > people serialising their data, it's a nuisance and definitely not as > core as xsi:nill. Who says consensus on specifics is needed? Why not just expect to have two or three dominant profiles? The whole consensus argument is bogus. We need profiles *because* people cannot agree. There is no need for consensus. All that a profile needs to do is be helpful for some significant group. If the intent of the profile were to replace XML Schemas, then consideration of "80:20" and its uncertainty might be relevant. But I don't think that would be the intent at all. Some significant group comes up with a profile. They say "this is all we want to/need to/intend to/should/commit to use". It gives vendors, integrators, developers and purchasers a better common ground. W3C helps by refactoring the XML Schemas spec to cope with the kinds of issues raised by the Workshop and others: the runtime typing issue for example. A profile not only limits the features in XML Schemas used, promoting incomplete implementations, but it also provides a bottom line, and so promotes *more* implementation of core (to that profile) features. For example, if there is a significant group of vendors who simply cannot implement mixed content (and there may be all sorts of good technical reasons), then let them make a profile and advertise, say, "We support XML Schemas, but only the 3NF.ORG profile". Users then know what the limitations are of the tool and can figure out what their interoperability response should be. I don't see that developers who cannot support every feature of XML Schemas are villains or morons or spoilers. But the current complexity and monolithicity/ spaghettitude/under-layering of XML Schemas doesn't give them any way to be good citizens. Cheers Rick Jelliffe 
|
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
|
|||||||||
