Re: [xml-dev] The purpose of a namespace URI is ...

[Fraser Goffin <goffinf@gmail.com>]

I am a supporter of that approach, however I see real practical
problems because it makes assumptions or sets expetations about how a
message will or should be processed.

In a closed community you *might* be able to be more certain of that,
but outside of that it is probably unrealistic. My experience is that
even within the relatively controlled environment of messages passed
between internal applications there are a large variety of processing
approaches some of which are entirely incompatible with the way in
which we would prefer, and for consumers of messages outside of the
organisation, we really can't make any assumptions at all. Sure we can
construct an NDR but when that challenges the ability to do business,
you're never going to win that argument.

It's a hard question and in many ways is related to how we version
schemata, how (and if) we allow for non-author extensibility, whether
we prefer strong typing, how we might understand what are consumers
care about (aka: consumer driven contracts), validation by projection,
open content models vs. highly prescriptive (and possibly brittle)
types, ......

It seems every year I go round and around this one. Actually if XSD
1.1 were more widely used things might be a bit easier ... But then
again, I sometimes find myself telling my service designers colleagues
not to get too focused on XSD because of its lack of expressiveness or
because it's limitations tend to 'leak' into service specifications
...

Sorry I'm rambling ... I'll stop.

On 30/11/2012, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> At 2012-11-30 20:28 +0000, Fraser Goffin wrote:
>>On 30/11/2012, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
>>
>> > As soon as you touch the namespace string, all downstream processes
>> > relying on the qualified names break.  If different versions of a
>> > vocabulary have slightly different semantics (or putting it another
>> > way: predominantly the same semantics), the language definition
>> > should tell an application how to accommodate forward and backward
>> > compatibility.  The vocabulary itself is identified by the URI
>> > string.  The application can determine the version.
>>
>>Didn't read this bit closely enough first time. Are you alluding to
>>approaches like 'must ignore unknown' as the 'language definition' or
>>am I reading too much into that ?
>
> That was my intention, yes ... when defining an XML vocabulary such
> expectations for forward and backward processing should be spelled
> out.  What to do when something arrives that was supported but is no
> longer supported (I wouldn't expect many of those) and what to do
> when something arrives labeled as part of the vocabulary that isn't
> recognized (that is important, even if it is to say "this is an
> error").  Also, what to do when something arrives that is foreign to
> the vocabulary (e.g. foreign attributes attached to a known element,
> and foreign elements that are under a known element).
>
> . . . . . . . . Ken
>
>
> --
> Contact us for world-wide XML consulting and instructor-led training
> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/
> G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
> Google+ profile: https://plus.google.com/116832879756988317389/about
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>