[
Lists Home |
Date Index |
Thread Index
]
The problem with writing to a news-list is that good arguments can
often sneak in under the radar as you're writing your response.
If you remove DTDs, you still need to have some mechanism that
replaces those DTDs with something else. XSD don't hack it - its
singularly poor at expressing those very things that people keep using
DTDs for. Relax-NG is a little closer, and personally would be
superior to both XSD and DTDs in that regard, especially once you
provide an alternate mechanism for entities.
I would be VERY careful about playing with preprocessors. I think this
was one of the problems that caused problems for both SGML and XML in
the first place. I have an intrinsic distrust of processing
instructions, as they by their very nature reduce portability of XML.
This has always been something that's bothered me about Microsoft
markup in particular - they LIKE PIs, even as the rest of the world
seems to have moved away from them.
I also think that for all that I would love to see CDATA sections
become ancient history, they are necessary - simply because a CDATA
section can (pretty safely) encapsulate text that has syntactical
markup, something that will be true regardless of what symbols are
used for denoting that section. I should also point out that CDATA
sections become almost necessary when dealing with "unsafe" content -
XML wrappers holding blog feedbacks written by people who don't have
the first clue about why ampersands in text are bad for your
application, or for situations where you don't WISH for your XML to be
interpreted (such as examples given in a textbook). CDATA exists
because you need to have a way of escaping content from
interpretation.
Several years ago, there was a movement to "simplify" XML, with a lot
of mud being slung on both sides. Significantly, after a while, the
argument died away, because of the realization that any simplification
of XML reduced its use for others who found their core needs no longer
met. I think that by forking XML yet again, you run the risk of
marginalizing yourself with a use case that buys you some efficiency
gain for a limited set of applications at the cost of reducing
flexibility, despite the fact that it is that very flexibility that
makes XML so attractive for such a wide number of use cases.
On Sun, 6 Feb 2005 12:51:15 -0500, Michael Champion
<michaelc.champion@gmail.com> wrote:
> On Sun, 06 Feb 2005 08:47:32 -0700, Uche Ogbuji
> <Uche.Ogbuji@fourthought.com> wrote:
>
> >
>
> > If you insist on this "hand-written XML is obsolete" theory enough to
> > use it as a case for focusing XML 2.0 on toolkits, you're going to have
> > to come up with a lot of evidence to back up your dubious claim.
>
> I didn't say "obsolete", I said it's not the mainstream use case for
> XML I see. XML 1.0 appears to have included a lot of stuff to make
> it easier to hand author, and in my non-expert opinion is that stuff
> seems to be causing a disproportionate amount of the pain for
> developers. I'm not presenting that as a conclusion that I wish to
> defend, just a reason for being interested in a profile of XML that is
> focused more on the feature that are most valuable to the mainstream.
>
> The point that hand-authored XML may be a small percentage of the
> volume but it is more important as assets in the typical system is a
> very interesting one that I'll have to think about. I wouldn't even
> begin to dispute that this was true in the early days, but I think XML
> is pretty well bootstrapped now. The text format that allows "hand"
> tweaking and debugging is definitely a key part of XML's value, but
> that's not what I'm talking about.
>
> My personal preference (really a best guess, since I haven't tried to
> really design or prototype it) would be to remove DTDs and maybe some
> other bits such as the highly confusing whitespace rules, CDATA
> sections ... out of the XML *core* and put them in some spec that
> governs what a preprocessor would do to turn that syntax sugar into
> the minimized core syntax, e.g. translate character entities into
> Unicode, escape the individual characters that need to be escaped
> inside a CDATA section, etc. I have no desire to make the syntax sugar
> obsolete, I just don't see a long-term value for baking it into the
> very core of what XML is. People who find that stuff useful for
> hand-authoring or vendors who need backwards compatibility with SGML
> and XML 1.x can stick with it, fine with me, they just would have to
> use the preprocessor along with a hypothetical "XML--" processor in
> their work.
>
> Again, I don't really know if this would improve the REAL value of XML
> or just its geek appeal to me. I think that's an open question, and I
> freely admit that we all have different takes on this from our work
> experience. The reason I babble about this is to stimulate feedback
> from others so as to get a balanced perspective.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
Kurt Cagle
http://www.understandingxml.com
|
