Well, first off, I am somewhat baffled by this tangential post. I was talking about fitness of solution to the problem, and not bugs, per se, at all. Also, I am not sure what "rule" is implied here. Leaving these issues aside, I would like to respond on two points: appropriate application of XML and schema design issues.
First, by dusting off that old Kenton quote (a favorite of technology salesmen everywhere), are you implying that just because MS Word "ain't broke" is no reason _not_ to foist deep XML structures upon CMS users? Sorry so polemic, but I feel I am responding in kind.
Deep XML structures are seldom a good idea. Sometimes they are an excellent idea. In any given case, how do you know which it is? That's easy: when the cost of data collection is less than downstream cost reductions - preferably by a factor >3 within a year or so.
Deep XML structures are largely unproven. They will be adopted initially by those applications where the benefits clearly outweigh the risks and costs. Generally, the shallower the XML structure the better.
A good analogy is OODBMS vs. RDMBS. OO databases have their uses, but they are not the best choice for most applications. In fact, most OO software requires RDBMS. With the relational model, the same data may be projected onto different objects at different times. Because of this looser coupling, it is easier to view, for example, the same product info as part of an order, an invoice, an inventory replenishment order, a shrink report, etc., etc.
Most business people don't even want to think about data or systems coupling issues. They just want to write some docs and get them published here and there. A Chevy is just fine. Let someone else buy the Caddy.
Second, you do not respond to or acknowledge some of the difficulties in defining flexible XML schemas. Specifically, XSD makes it difficult to define elements as containers for XHTML. At best, it is a cumbersome, brute force task.
This is a practical issue that schema designers must grapple with. If you look at a schema like DocBook, it freely mixes presentation data with metadata in one document. This is a good thing - in principle. Now, if you wanted to use XHTML for the presentational elements, you would have difficulty.
To give a simple example, think of a FAQ XML Schema. Say you want documents like so:
<?xml version="1.0" ?>
<FAQ:FAQ id="price-of-beans.faq"
xmlns:FAQ="urn://xmlns.example.com/faq/">
<FAQ:Q>What is the price of beans in China?</FAQ:Q>
<FAQ:A xmlns="http://www.w3.org/TR/REC-html40";>
<!-- IN HERE, YOU JUST WANT AN XHTML FRAGMENT -->
<p>I'm glad you asked that question. I'd like to answer
that question by asking another question:
<a href="price-of-milk.faq">What is the price of
Milk in France?</a>
</p>
</FAQ:A>
<FAQ:Property name="language">en</FAQ:Property>
<FAQ:Property name="country">cn</FAQ:Property>
<FAQ:Property name="topic">Economics</FAQ:Property>
<FAQ:Property name="subtopic">Beans</FAQ:Property>
</FAQ:FAQ>
This works fine either without a schema at all or with a content model of "any" for FAQ:A . Either way, app level validation is required and it is not the stuff of deep XML structures.
Extra credit questions: What if the same question may appear in multiple categories (aka FAQ "documents")? Loose coupling (aka shallow structure) is your friend. What if you want to (or have to) allow sloppy HTML in FAQ answers? That's actually easier. Just use #PCDATA content model and wrap the content in a CDATA section. Alternate solution, convert answers to XHTML first with HTML Tidy. [tip: a hack I like for quick-and-dirty FAQs is to use the HTML DL, DT and DL tags]
So, in summary, I share the general interest in XML content editing. In fact, I have implemented it a few times. Heck, I even wrote a web-based, DTD-driven XML editor. But I see no reason why it cannot or should not be deployed side-by-side with Word editing in the same CMS. They are not mutually exclusive in the least. I do think that it is entirely reasonable for folks to avoid the hassles of XML if they don't have any of the problems it happens to solve.
take it easy,
Charles Reitzel
P.S. Last I checked, most cars still use the same internal combustion engine technology as the Model T. But, hey, it ain't broke. Although, with global warming, it's days are numbered.
P.P.S. Sorry such a long-winded post. I'll shut up now. <g>
At 12:34 PM 12/21/2002 +0000, Nuno Lopes wrote:
DISCLAIMER: I've never been pro Microsoft or Pro J2EE, Open Source or anything defined in such abstract term
Hi all, answering to Charles.
Any technology as problems and bugs is just a matter of choosing whose bug's one wants to correct IMO.
"Don't fix it if it ain't broke" presupposes that you can't improve something that works reasonably well already. If the world's inventors had believed this, we'd still be driving Model A Fords and using outhouses.
- H.W. Kenton
This rule is even gentle to XML Editors and XML Technologies in general in all scopes (price, robustness, usability) by considering that they work reasonably well already (Probably in 2 to 5 years).
Best regards,
Nuno Lopes
Independent Consultant
-- http://cms-list.org/ trim your replies for good karma.
