[
Lists Home |
Date Index |
Thread Index
]
>
> On 14 Jul 2005, at 05:02, Rick Jelliffe wrote:
>
>> "There appeared to be no obvious way to split the XML Schema
>> specification
>> into layers or sub-languages"
>>
>> So XML Schemas is such spaghetti that it cannot be untangled? Yikes.
>> But I don't believe it.
>
> The difficulty in splitting the spec into layers or shells is that
> there isn't consensus on which features are core and which are
> esoteric. You're 80 is my 20 was order of the day and highlighted
> in Paul Biron's summary of the experience reports.
Err??, that quote came from you. If it not true now, please revise your
report! (Otherwise it just joins the morass of FUD against any change.)
(The purpose of the split that I mention was demonstrate that there
is at least one way that the structures spec and XML schemas could be
refactored. It isn't important whether it meets my 80 or your 80:
all it needs to do to be plausible is to look like meeting *some*
groups' 80.)
>> One problem with a monolithic spec is that it gives little
>> guidance about what is core and non-core. Everything is
>> core. A more layered spec such as I suggest would clarify
>> that, for example, mixed content is a core feature but xsi:nill
>> is not.
>
> Which I think, proves my point. Whilst I agree that mixed content is
> core - from my perspective it's what XML is all about, but for many
> people serialising their data, it's a nuisance and definitely not as
> core as xsi:nill.
Who says consensus on specifics is needed? Why not just expect to
have two or three dominant profiles? The whole consensus argument
is bogus.
We need profiles *because* people cannot agree. There is no need
for consensus. All that a profile needs to do is be helpful for some
significant group. If the intent of the profile were to replace
XML Schemas, then consideration of "80:20" and its uncertainty might
be relevant. But I don't think that would be the intent at all.
Some significant group comes up with a profile. They say "this is
all we want to/need to/intend to/should/commit to use". It gives
vendors, integrators, developers and purchasers a better common
ground. W3C helps by refactoring the XML Schemas spec to
cope with the kinds of issues raised by the Workshop and others:
the runtime typing issue for example.
A profile not only limits the features in XML Schemas used,
promoting incomplete implementations, but it also provides
a bottom line, and so promotes *more* implementation of
core (to that profile) features.
For example, if there is a significant group of vendors who simply
cannot implement mixed content (and there may be all sorts of good
technical reasons), then let them make a profile and advertise, say,
"We support XML Schemas, but only the 3NF.ORG profile". Users then know
what the limitations are of the tool and can figure out what their
interoperability response should be. I don't see that developers
who cannot support every feature of XML Schemas are villains or
morons or spoilers. But the current complexity and monolithicity/
spaghettitude/under-layering of XML Schemas doesn't give them any
way to be good citizens.
Cheers
Rick Jelliffe
|
