OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Schema-Specification normative preference wasRE:[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace


I do not understand where David's implication
was drawn from. Certainly having a schemaLocation
for a schema does not necessarily mean that there
are no local caches. There are also nowadays some high
availability, fault tolerant, redundant, failover, load balancing
systems. 

This means that though there is one URL,
there need not be, in any pejorative sense, "a single
point of failure". A system backup is also possible.
DNS IP pools for the host, parallel live systems
running in sealed tunnels in Colorado, etc.

What does any of this have to do with updating
a schema as a work-around for an interop. problem
arising from a discrepancy between normative words in a
specification and the normative schema of that
specification.

I guess I must be missing something.



-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Monday, February 18, 2002 2:38 PM
To: David Fischer
Cc: Dale Moberg; Christopher Ferris; Doug Bunting; ebXML Messaging
Subject: Re: Schema-Specification normative preference wasRE:
[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace




David Fischer wrote:
> 
> IMO, it is tantamount to insanity to make world-wide eBusiness via
ebXML
> dependant upon a single schema in a single location.  If that location
becomes
> unavailable, does that mean all eBusiness throughout the world will
stop?!?  
>>>>>>>>>>

I concur with David's concerns.  In fact,  it is written in the
Technical Architecture document that no one single point of failure is
acceptable within the architecture.  Therefore,  I would assert that a
different approach would have to suffice.

When I reviewed the document, it was unclear what we were using
namespaces for.  Is it to simply differentiate elements which MAY
conflict (aka namespace support for XML v 1.0) or are we really trying
to import a schema definition (aka #sC schema import feature).  If the
latter,  please justify this decision.

Thanks

Duane Nickull
-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC