RE: Visibility modifiers for named Schema components -- Schema 1.1 feature?

Mark, I agree with you that it would be useful to have finer control over
the visibility of top-level definitions and declarations - though I can't
say I know exactly what the right answer is.

I think your use case raises another point, however, which is the fact that
it's entirely reasonable for more than one schema to exist for the same
namespace. The spec seems to be very confused about whether this is a good
idea or not. I think it is both good and necessary, for example it allows a
document recipient to test whether an incoming document conforms to a
locally-restricted subset of the message space. What this means, I think, is
that it's incorrect to assume (as xs:import does, for example) that you can
identify a schema by its target namespace alone. In practice people end up
using schema location to distinguish the schema, which seems undesirable.
There should be a separate URI that identifies the schema itself, and it
should be possible to specify this URI in xsl:import, for example, to avoid
any ambiguity about which of the possible schemas for a namespace is being
invoked.

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Mark Goodhand
> Sent: 14 September 2006 09:18
> To: xmlschema-dev@w3.org
> Subject: Re: Visibility modifiers for named Schema components 
> -- Schema 1.1 feature?
> 
> 
> On 8 Sep 2006, at 16:05, David Ezell wrote:
> > Both of the following comments seem to have merit, but it's either 
> > unclear how to implement them or why they'd be important in XML as 
> > opposed to OO.
> >
> > N.B. when I joined the schema WG I was an OO programmer, and it was 
> > not at all clear to me what was good for OO wouldn't be 
> good for XML.  
> > The reasons this logic really doesn't hold completely are 
> subtle, not 
> > completely self-evident, and therefore unsatisfying.  I offer the 
> > following comments realizing that you'll have to buy in to 
> this idea 
> > before you see my answer as anything other than sandbagging.
> 
> 
> Hi David,
> 
> Thanks for your response.  It's quite possible that I've got 
> the wrong end of the stick, and that what I'm suggesting is 
> fundamentally opposed to the logic of XML Schema.  From what 
> I do know of Schema, I wouldn't be at all surprised if the 
> reasons turn out to be subtle :-)
> 
> Please find responses to your specific questions within ...
> 
> 
> > Mark Goodhand wrote:
> > > I've long found it frustrating that in order to reuse schema 
> > > components, you have to make them global.
> >
> > You mentioned that you are frustrated by this fact.  Can you 
> > elaborate?  Is that databinding doesn't work as you expect, or some 
> > other problem?
> 
> 
> At one level the frustration stems from the fact that "it 
> just seems Wrong", but this post was motivated by a practical 
> difficulty.
> 
> We encountered an incompatibility between the XLink schema 
> created by the OASIS CIQ TC, and the XLink schema used by 
> XBRL.  Core XBRL schemas relied on the existence of named 
> components in the XLink namespace, which were defined in the 
> XBRL XLink schema, but not the CIQ XLink schema.
> 
> Arguably, the symbol spaces in the XBRL XLink schema were 
> polluted -- they contained components not mentioned by the 
> XLink spec.  The creation of the components was motivated by 
> a perfectly reasonable desire for internal reuse, but this 
> "implementation detail" was exposed on the "public interface" 
> (because the set of named schema components available to 
> other schemas is the same as the set of named schema 
> components available internally).  This created the 
> opportunity for other schemas to *rely* on the unofficial components.
> 
> I believe the CIQ schemas similarly relied on components that 
> weren't mentioned in the XLink spec.  If you're interested in 
> further details, let me know.
> 
> 
> > Many members of the Schema WG believe that you should be able to 
> > create local complex types and reuse them at that scope, assuming 
> > that's what you're requesting.  (Note that the schema 
> component model 
> > could allow this construct, but the XML serialization syntax has no 
> > way to express it.)  This belief (which I've held at times and may 
> > hold again) is IMO based in the idea of OO scoping.
> 
> 
> That level of scoping may be useful.  I was proposing 
> visibility control at a document level -- e.g. a top-level 
> type that can be reused anywhere within its containing 
> document, but (if marked as
> 'private') not available for use in any other schemas.
> 
> 
> > You have to remember that you can't hide data in XML.  It's 
> not that 
> > the idea is bad, it's that the two systems are not isomorphic.
> 
> 
> It's true that XML Schema "source" is more likely to be available  
> than (say) Java source, but
> 
> 1) Even when you can see source (e.g. in any open source project),  
> the compiler-enforced distinction between implementation and  
> interface is still useful, and
> 
> 2) As I understand it, XML is just one possible serialisation 
> for XML  
> Schemas -- the Schema spec allows Schemas to be stored in 
> opaque, non- 
> XML forms.
> 
> Perhaps you weren't thinking about source when you said that "you  
> can't hide data in XML".  Perhaps you meant that the schema 
> component  
> model is public (e.g. exposed through such interfaces as the  
> org.apache.xerces.xs XML Schema API).  Even at this level, I'm not  
> really interested in hiding anything, I just want Schema processor- 
> enforced constraints on the *use* of schema components.
> 
> Does this make any sense, or am I talking rubbish?
> 
> Mark.
>

Received on Thursday, 14 September 2006 09:03:39 UTC