[
Lists Home |
Date Index |
Thread Index
]
That would suggest that creating a subset is a fool's errand.
Ok, that is an overstatement.
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? 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?
To me, it keeps coming back to what services can a
programmer reasonably expect of an XML processor.
If that beast is an illusion, than all we really
have is portable data without semantics. We
don't have interoperability or we don't have a
clear definition of interoperability and among
other things, the TAG draft architecture document
does indeed have a large definitional hole in it.
People are creating interoperable code, but it
would be ad hoc based on shared illusions about
what the XML infoset(s) mean. XSLT, XPath, etc
work, but largely because of vendor ubiquity,
not the rigor of the specifications that define
them. All the specs/standards are creating is
large costumed fiefdoms, not an open system.
That doesn't sound right to me. Maybe I am just
a fool. :-)
len
From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
On Tuesday 25 February 2003 09:48 am, Bullard, Claude L (Len) wrote:
> Argggh.... We have a real problem then and
> I'm not sure how to describe it except other
> than to talk about infoset services. In other
> words, how do I know what an XML parser does
> in terms of real code? It would seem to me
> as others (eg, Rick Jeliffe) has suggested,
> that is the problem to be worked before the
> W3C launches into a subset activity.
I think this is an important area to look into, but I haven't seen any way to
really resovlve the issue. Applications are specific to a problem domain, and
more often than not, so it the data they manipulate.
> Otherwise, XML interop is a
> myth beyond knowing a file is well-formed.
That's the state of the world... perhaps a bit better because we do have a few
standardized API's. I'm not sure that can ever truly change without a
paradigm shift in programming.
|
