[
Lists Home |
Date Index |
Thread Index
]
> 10/11/2002 12:00:24 AM, Uche Ogbuji <uche.ogbuji@fourthought.com> wrote:
>
>
> >This sounds like the rallying cry of the Knights of Tag Soup.
> >
> >Validation is mostly an obstacle to evolution if designed using the wrong
> >tools in careless hands.
>
> That's a great turn of phrase! Still, I guess I think of myself as at
> least the jester in the Court of the Knights of Tag Soup, so maybe I
> should ask Uche or someone else to educate me on the point.
>
> Uche's point was a response to a response to something I wrote:
>
> > 2 - Namespaces - work best for mixing instances of well-defined
> > vocabularies/schemas together, they don't work so well to support
> > evolution or un-typed XML. Schema evolution using namespaces is
> > a Known to Be Hard, TAG-level problem.
>
> I'm under the impression that managing schema evolution
> is a Hard Problem;
Managing any change is hard. Well-designed schemas make the task easier. The
problems are more in the open when you have a schema, to be sure, so perhaps
it is easy to suffer the illusion that it is the schema itself that is causing
the difficulty.
I've been doing a lot of work in RSS processing recently. I can assure you
that the problems in code related to format evolution and chaos dwarf the
well-known problems of schema evolution. I can see this fact plainly in the
code.
> lots of the complexity
> of WXS is there to make the problem more manageable by employing
> notions of partial re-use that come from the OO world,
It was always a blatant lie that OO had anything special to offer to the goal
of software re-use. I, personally have always regretted spending so much of
my professional career learning this sad fact.
The slavish copying of failed OO concepts is one of the main problems in WXS,
including its OO-tainted attitude towards class and type.
I've posted at length on these matters before.
> but it's
> not clear to me that best practices have emerged for using it. We've seen
> lots of threads on how best to use namespaces in the context of
> evolving schema (the famous XHTML "3 namespaces" flamefest come
> to mind!). I just don't get the impression that this is a situation
> where the technology is well-understood but carelessly applied.
> Do people here disagree?
I disagree. In my experience, case where I think schemata have been well
designed, change management is easier. In other words, I don't recognize a
difference between best practice for schema design and best practices for
evolvable schema design. As I see it, good schemata are relatively evolvable
schemata.
BTW, I think you make more of namespaces in this discussion than necessary.
Namespaces are just part of element/attr names, and thus just another cog in
the wheel of schema design.
> On the other part of my original assertion: Am I missing something?
> Namespaces in XML seems obviously written for the scenario where
> elements and attributes from different *well defined* namespaces are
> merged in a single document. The critique from the Architectural
> Forms advocates has been (to the best of my ability to repeat it):
>
> The namespaces spec assumes that every element is in one and only
> one namespace. But when you have decentralized schema
> authorities whose output must be amalgamated this assumption is untenable.
>
> The "decentralized schema authorities" is more or less what they have in the
> RSS world, and in lots of other real-world situations where people are mailing
> around schema fragments, templates, and examples in order to figure out what
> format the data are supposed to be put into.
I must say I really don't understand the progression of argument in the above
three paras. I'm not sure what the fact that people often flout any rules
they think they can get away with has to do with the viability of namespaces.
If you follow the rules relating to namespaces, then you are likely to find
them useful (if not necessarily ideal). If you don't, then you are likely to
gain nothing from namespaces. This seems a plain truism to me, so I must have
missed the point.
> So, two questions: Is this a matter of "the wrong tools in careless hands"?
> I guess I balk at calling people "careless" if they're just doing what they
> have to do in an unmanaged environment where there is no "schema authority",
> (or the "schema authority" is locked in analysis paralysis in a meeting room
> somewhere!). Or am I missing the point here?
Maybe you're too kind. When people write HTML that is browser-specific or
inaccessible, I call them careless. Why should I not also call those careless
who misuse the tools of XML?
> Finally, how DOES one make XML technology choices that are not fragile in the
> face of human nature? So much of traditional SGML/XML technology seems
> predicated on the assumptions underlying the "waterfall model" of software
> development.
I find this statement astonishing. To me, XML technologies follow the exact
opposite of the waterfalls cycle. They are designed from scratch to
accommodate the vagaries of human nature, and this is not contradicted by the
fact that they provide 2 tools in order to establish some bounds on chaos:
well-formedness and validity.
Can you explain what in XML you associate with waterfalls? For any example
you give, can you offer an example of another technology that does not suffer
that weakness?
> On the other hand, the Knights of Tag Soup can just deal with it, with
> whatever witches brew of schemas, namespaces, architectural forms,
> Schematrons, pipelines, regexp's, XSLTs, etc. that has to be conjured up
> for a specific need. I don't think that's anything to sneer at!
Again, I'm missing a point somewhere. I use "schemas, namespaces,
architectural forms, Schematrons, pipelines, regexp's, XSLTs, etc." all the
time to solve practical problems. Somehow I have never construed this fact as
an excuse for careless design.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/py.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/index.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/index.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerworks/xml/library/x-tipgenr.html
|
