[
Lists Home |
Date Index |
Thread Index
]
3/2/2002 10:18:22 AM, Niels Peter Strandberg <nielspeter@npstrandberg.com> wrote:
>Why do we use XML to validate, manipulate, transform etc. other XML
>documents, fragments?
>
>I want to do my work in Java or another language, not a XML "language"
>like XSLT, XML Schema etc.
If you're implying that there is no reason one can't use procedural
code to do transformation and validation on XML data, you're right.
The choice of XSLT or SAX/DOM procedural code for this is a matter of
taste and convenience. I agree with a quote from Adam Bosworth:
"it's been our experience that simple things should be declarative,
but hard things should be procedural. Corporate developers have no trouble
dealing with code; they do have trouble dealing with very rich, abstract
languages."
http://www.infoworld.com/articles/op/xml/02/01/21/020121opcurve.xml
>
>I want XML in Java! Why not like this:
>
>
>Stylesheet style = {
>
> <XSL:STYLESHEET {
> [xmlns.xsl = "http://www.w3.org/1999/XSL/Transform";]
> [version = "1.0"]
>
If you're saying that the syntax for declarative languages
used to describe and process XML could be more Java-like, well, there are
a number of people lurking out there experimenting with this idea ...they
can chime in here if they want to go public. Some people who like Python
syntax do do this sort of thing have developed a spec called YAML ...
see www.yaml.org, although they have diverged somewhat from the XML data
model.
There *does* seem to be a trend toward defining alternate non-XML syntaxes
for such things; for example, the XQuery people seem to have decided that
their initial requirement for an XML version of the query syntax doesn't
meet a strong real-world need, and the RELAX-NG people have defined an
alternate typist-friendly syntax that directly maps onto the normative
XML syntax.
I'm sure this is controversial, but a case could be made that
"XML" is more than the angle bracket syntax; the InfoSet and the DOM
can be thought of as "XML" and they operate on the output of a parser
and don't care about the syntax that the parser understands.
SOAP 1.2 is defined on the InfoSet rather than XML syntax, so in principle
a SOAP message can be encoded in a URI ... or <heresy> a Java-like syntax
such as you describe that would eliminate the pain of mapping programming
language data structures to WSDL</heresy>.
There are parsers that take non-angle-bracket syntax and generate SAX events
(I can't point to any offhand) and there is a DOM Abstract Schema use case
for using it to describe RDBMS schemata as well as various XML schemata.
Likewise, we had a thread a month or so about "Smart ASCII" as a way of
hand-authoring documents that are then turned into XML (syntax, but
it could produce a DOM tree or SAX events too). That reminded us of the
fact that XML standardized the SGML "concrete reference syntax." but
SGML has the power to map just about any regular syntax (LISP, Java
data structures, structured ASCII) onto SGML groves or whatever.
I'm a bit torn: On one hand, while XML syntax is often a pain in the
butt, it's "standard", and a mediocre standard is better than fragmented
"better" alternatives; on the other hand, we seem to find ourselves
spending a lot of time reinventing perfectly good wheels just to make them
roll on XML's highway. Maybe it would be worthwhile to spend that effort
figuring out how to map things like Java data structures directly on to XML's
data model, and refining the data model to handle things (such as graphs)
more cleanly. That wouldn't kill XML, just redefine the angle brackets
as the "reference syntax" and put the InfoSet at the center of its universe.
|
