[
Lists Home |
Date Index |
Thread Index
]
On Tuesday 25 February 2003 11:28 am, Bullard, Claude L (Len) wrote:
> You've said what you think is the right layer of the
> XML-SW suggestions. Even given your comments here,
> do you think an XML-SW plus a matching infoset is
> worth pursuing in response to the requests for a
> subset, or is it up to each application to define
> such?
I personally don't see the real need for a subset from an application-building
perspective, but given the amount of consternation other people have, I would
say there is probably some value in a syntax subset.
Assuming there is to be a subset, it should be just that, a subset. Remove
anything that is not directly a syntax issue. That'd bring us right down to
UnicodeAndAngleBrackets.
I have no problem with defining a canonical Infoset/data model, so long as it
is not part of the syntax specification. In fact, I can easily imagine two:
one for syntax-driven applications, and one for "structure" driven
applications.
> If they do, should they create individualized
> processors to match their specifications, should they
> rely on the XML processsor provided in the library
> of framework objects provided by a vendor, or is this
> a mix and match challenge?
You'll have to excuse me here, because you're leaping from syntax and infosets
to software components. That leap is a source of confusion IMHO.
> To me, it keeps coming back to what services can a
> programmer reasonably expect of an XML processor.
What is "an XML processor"? A parser? A bean serialization package? SNOBOL? If
I have a toolkit that parses RTF, but which generates a SAX2 compliant event
stream, is that "an XML processor"? Is JAXM defined in terms of the XML
infoset?
FWIW. I think, apart from the obvious beauty and elegance of the XML syntax,
XML itself offers little to the programmer. I mean, seriously, if you're
developing a distributed application, do you care that the message is in XML,
or rather, that you can use JAXM to get the work done? Why?
|
