[
Lists Home |
Date Index |
Thread Index
]
On Mon, Mar 04, 2002 at 10:47:04AM -0800, Tim Bray wrote:
> At 04:36 AM 04/03/02 -0500, Daniel Veillard wrote:
> > It's just a matter of API level. As parts get used more they
> >gets forged as API. Better building API at a syntax level than
> >in the programing language syntax. I call this sedimentation...
>
> That's precisely what I'm disagreeing with... I'm becoming
> more & more convinced that inclusion and aggregation have so
> much application-specific hair, and the cost of trying to
> model them generally is so high, that we should just kick
> them out of the syntax and at the level of *interoperability*,
> we should talk in terms of whole fully composed XML documents.
<ot>
I would be tempted to tease and ask what is an XML document (would
the TAG ever find the answer ;-) . I also note that in use case like
the Jabber protocol, you never end-up with a "fully composed document"
it only exists once the processing is finished and that it had become
useless.
</ot>
But to stay in line with the previous discussion, the cost of the
modelling has IMHO been mostly done once the Infoset was defined. At that
point one have a model of a document instance and it becomes possible
to define *one* semantic to document merging. I doubt that there is
any disagreement about the fact that defining that merge operation is
an useful base concept. As you pointed disagreement can arise about
variation in semantic about that operation. And in such case defining
one predefined semantic, the XInclude one help those who can use it.
The debate is not whether to build it into syntax and infrastructure,
but whether it's possible to define one semantic which fits a large user
base. So far with the added ID fixup I personally find it useful, it's
in CR and there is already some implementations. The key point is that
it doesn't prevent people from using perl/python/whatever language to
define their own merging semantic if they have a different need. And
XInclude won't be less interoperable than those custom processing tools.
You say "the cost is too high compared to the potential user base",
I just say "maybe, but the work is mostly done and it may get more
users than what you expect".
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
