W3C home > Mailing lists > Public > xmlschema-dev@w3.org > July 2002

RE: restriction question

From: Mark Feblowitz <mfeblowitz@frictionless.com>
Date: Tue, 23 Jul 2002 10:06:55 -0400
Message-ID: <4DBDB4044ABED31183C000508BA0E97F040ABDF8@fcpostal.frictionless.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>, xmlschema-dev@w3.org

Yes - and it simply kills any notion of having layered namespaces (defining
concepts in ns1 and restricting them in ns2).

That's one of the many reasons we (OAGI) decided not to use any derivation
by restriction.

Mark


Mark Feblowitz                                   	
XML Architect
       [t]   617.715.7231                                     	
       [f]   617.495.0188
Frictionless Commerce Incorporated 	
       [e]  mfeblowitz@frictionless.com
       [w] http://www.frictionless.com
       [m] 400 Technology Square, 9th Floor
             Cambridge, MA 02139 
Open Applications Group Incorporated
       [e]  mfeblowitz@openapplications.org
       [w] http://www.openapplications.org 

 -----Original Message-----
From: 	Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent:	Tuesday, July 23, 2002 5:10 AM
To:	xmlschema-dev@w3.org
Subject:	Re: restriction question



> What I would like to do is restrict a type from a foreign
> schema/namespace -- which I have no control over -- in a namespace
> that I do have control over, and I would like to have the default
> namespace be equal to the target namespace in my schema. Is this
> possible? If I have understood you properly, then this isn't
> possible if the foreign namespace schema has elementFormDefault set
> to 'qualified'. Is this correct? Do I have to not use the
> xmlns=targetNamespace?

I forgot to make a more general observation on this point, that this
illustrates one situation in which the "Venetian Blind" pattern
(global complex types paired with local element declarations) doesn't
work particularly well.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Tuesday, 23 July 2002 10:07:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC