On 14 Sep 2006, at 17:56, noah_mendelsohn@u... wrote:
> What I hear Mark asking for is visibility control of named components,
> e.g. the ability to restrict visibility to the document in which the
> declarations or definitions occur.   First of all, I can see the  
> use cases
> for this.  That said, the schema languge is rightly criticised for  
> being
> too complex, having too many little switches and features, being  
> too hard
> to learn, and taking too much effort to implement.  I can't see a  
> way to
> meet this "requirement" without adding yet more features, yet more
> implementation complexity, yet more testing complexity etc.   
> Further more,
> as I once said in a talk, my experiences with the XML Schema  
> language have
> convinced me that "there's no such thing as a simple feature."   
> Taken in
> isolation, it's easy to see how access controls would work.  Maybe or
> maybe not they would prove to be a nice little isolated capability,  
> and
> largely orthogonal to the rest of the language, but I have my  
> doubts.  I
> can't point to any specific "gotchas" offhand, but it wouldn't  
> surprise me
> to find ourselves in a few months embroiled in some obscure discussion
> involving refinement, model groups or some such that involved  
> references
> to "private" components.
>
> I'm often reminded of the claim that was made by some members of the
> Schema workgroup that we needed to do locally scoped elements (another
> reasonable request) and that surely they'd be simple because local  
> scoping
> was known technology from other programming languages.  I can't  
> think of
> any feature that's caused more design complexity in practice.  To  
> pick one
> detail, the whole elementForm/elementFormDefault business would  
> never have
> come up had we done what DTDs did and had only globals (though  
> possibly
> with convenience syntax that would closely resemble today's ability to
> declare one element inside the content model for another.)
>
> So, I think that visibility controls are a sensible idea in  
> principle, but
> I would want to see very compelling evidence of the requirement before
> actually adding new features to the language.  I do note that some  
> mileage
> could be gotten from layered specs.  For example, someone could  
> specify a
> "HideMe" annotation, and could build tooling to ensure that no
> inter-document references were made to components so marked.  A little
> clumsy, but it nicely separates the concerns, I think.

Noah, Michael,

Thanks for your feedback.  I appreciate that seemingly simple  
features may have subtle interactions with existing Schema rules, and  
I can understand your reluctance to introduce visibility features at  
this stage (or, indeed, ever) without a compelling need.

I think there are work-arounds that can help with the specific issue  
we've come across (e.g. factoring 'helper' components out into a  
separate Schema, so as not to pollute the XLink namespace).

Using an annotation or non-xsd attribute to control visibility sounds  
like a sensible approach.  I imagine layered specs could also help  
with Michael's ideas about schema identification (e.g. paired unique  
identifier attributes on <import> and <schema>, paralleling the  
namespace-targetNamespace pairing).  I fear that without w3c backing,  
such features are unlikely to be widely implemented, but I'll see if  
there's any interest on the Xerces lists.

Mark.
-- 
Mark Goodhand, Development Manager     +44-1865-203192
DecisionSoft Limited                   http://www.decisionsoft.com
XML Development and Services