[
Lists Home |
Date Index |
Thread Index
]
I'd say that without such modularity, the questions of
what level of tool support is required are difficult to
answer or are not configurable In some cases as Simon notes, costs
will be passed to users who don't need the features they
are paying for.
My POV is formed by reading RFPs day in and day out,
and bidding a system that enables us to turn off unrequested
features on delivery, then turn them on if and when the
customer says, "I want that and here is a purchase order."
It isn't the philosophy or the techical requirements that
drive that; it is precisely the business case.
Jonathan said "use cases" and he is right. The data
typing tech has value but not all the time and in
every case. Simon and Jonathan are both right.
The problem, as pointed out, is that the specs
don't account for it. Are the costs significant
such that this has to be fixed? For that, without
use cases, it is argumentative.
len
From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]
> Yep. Don't build system dependencies into the core.
>
> On the other hand, can someone authoritatively say
> what is core and what is a system profile for XML?
<snip reason="to keep the email censor at bay" />
But there is certainly room for common sense here. As much as I find RDF I would be out of my skull to suggest mixing it into the core of XML. I would have hoped for such restraint from the application-specific data typing folks. I have no doubt they find their wizardry useful, and I'll even admit it is useful to me at times, but the whole is served better with proper modularity.
|
