[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: is that a fork in the road?
At 04:24 PM 3/2/01 -0600, Len Bullard wrote: >Who is offering what indigestible chunk? A fair number of people unfortunately. W3C XML Schema is an indigestible chunk by itself - add an attribute to an element lately? The requirements for XSLT 2.0 and XPath 2.0 suggest rather strongly that W3C XML Schema is going to become part and parcel of everyday XML processing. Then there's this minor dispute over how best to (not) integrate scripting languages with XSLT. All of these have substantial consequences which go beyond "well, no one's forcing you to use _that_ feature." >Henry? He is saying what the best and brightest >said before him and since: we are getting a >complex mess because we didn't have a robust >data model to begin with. I'm not sure that trusting the best and the brightest to solve our complex messes with robust data models is such a good idea. I think we might do better to let hard-working and somewhat more ordinary folks figure out how to use markup to solve their problems. > Which part of that >is unreal? All I am asking which I think >may be at the heart of this is do we have >to loop back into the base infoSet to fix >things. The pipeline metaphor can be >seen as a series of infosets, each one >different but building on what came before. Except that it's not a simple pipe. It's a complex set of substantially unpredictable interdependencies, where switching out components can cause data loss. On top of that, these aren't exactly tiny components any more. >Is that the idea? Sure hope not, given the current tangle. > If the idea is to remove >the bedrock of well-formedness, only the >bits on the wire have to right to begin with, >then I agree. What? What does "remove the bedrock of well-formedness" mean? And why exactly would you want to do that? From my perspective, that bedrock is all that's really stable here. > At the bottom of this, all >one gets is a well-formed character string. >That won't be enough for some applications. >The rounds in VRML proved it to me. Justin >makes it clear as Marrin did before him >that type information is a REQUIREMENT for >these apps to interoperate blindly. It's not a requirement for a substantial and rather enormous set of XML applications. Why inflict the rather controversial typing mechanisms of W3C XML Schema on every spec in sight? Why assume that every developer is going to be delighted to have this functionality around? Your requirements and my requirements are not the same, and your requirements may result in the creation of software that is in fact less useful to me. Why not build the specs in such a way that you can use the parts you need WITHOUT inflicting real costs on me? Right now, it looks like we're on the way to something perhaps even more complex than SGML. That seems like we've taken a rather severe wrong turn. "Interoperating blindly" sounds like a really deeply bad idea, to boot. I'd rather interoperate with my eyes open, thanks. >If you are talking about XML Query, the >jury is out on that. I can see the sense >of it from a perspective of how relational >guys like to write queries. I can see some >giant overlaps with XPath and the expressions. >I also see Jonathan saying over and over that >both spec owners are working on a convergence >to avoid messiness. And I see them reiterating >what Henry says so clearly: without a data model >it only gets worse from here. Given the deliberate 'patchwork' nature of the XQuery quilt, I'm not going to pound on that. However, I don't think the data model that's been proposed is healthy for XML, especially as it appears to be infecting and complicating far more than W3C XML Schema and W3C XML Query. >So I am really missing your point. Change seems >inevitable. Will it be ad hoc or planned? Given the results of recent planning, I'm certainly cheering for ad hoc. For this phase of development, I've got a lot more faith in competition than committee, and I'm counting on well-formed XML - and only well-formed XML - to provide a foundation for interoperability that lets us get through this probably contentious period. Simon St.Laurent - Associate Editor, O'Reilly and Associates XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books
|
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
|