[
Lists Home |
Date Index |
Thread Index
]
Sorry Len, this is a bit criptic for me (except the last part :-). I can't
tell if you're agreeing with me or Ken or neither of us ?.
Later on in this note I am also trying to assert that there is a difference
between a minor (non breaking) and a major (explicitly breaking) change and
that a vocabulary that provides no extensibility mechanism (for non schema
authors as well as schema owners) won't be flexible and fast moving enough
for business agility (I hate that term - but its late so it will suffice).
If it comes to a choice, the sacrosanct that Ken is talking about with UBL
will be sacrificed in a heart-beat. I'm not saying thats right, I just
saying, thats reality. So IMO we need to work extra hard to avoid that
condition appearing and if that means compromising (slightly) and not being
a slave to a difficult spec and a slow moving change process (show me a
standards effort that isn't !), then so be it. I have tried (v.hard) at
advocating the purview line and, as I'm sure you are well aware it is a
tough sell in the face of [short term] business delivery demands.
Do you have a view on this (silly question :-)
Fraser.
>From: "Bullard, Claude L (Len)" <len.bullard@intergraph.com>
>To: 'Fraser Goffin' <goffinf@hotmail.com>, gkholman@CraneSoftwrights.com,
>xml-dev@lists.xml.org
>Subject: RE: [xml-dev] Versioning of Enums
>Date: Mon, 13 Feb 2006 16:22:36 -0600
>
>A version-controlled namespace tactic that disallows minor
>changes without version number changes explicitly disallows
>the use of the standard channel to create a tipping point
>advantage covertly. This favors the strategy of openness
>and transparency of transactions and these in turn,
>simplify auditability.
>
>If in search of signal, I understand markup markets.
>Cheating in markup is like pissing in the party punch.
>Other bowls are provided for that: namespace URNs.
>If the pun escapes you, say it out loud.
>
>len (ogee, mr grodzins!)
>
>
>From: Fraser Goffin [mailto:goffinf@hotmail.com]
>
>I admit to being in the camp that says the addition of a new value to an
>enum does NOT warrant a new schema namespace (subject to the usual caveats
>about semantic coherence) ?
|