W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2006

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

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 14 Sep 2006 12:56:12 -0400
To: "Michael Kay" <mike@saxonica.com>
Cc: "'Mark Goodhand'" <mrg@decisionsoft.com>, xmlschema-dev@w3.org
Message-ID: <OF3A189615.C7381156-ON852571E9.005BA7F9-852571E9.005D09AE@lotus.com>

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.

> 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.

That's not quite how I'd look at xs:import without a schema location. What 
it says is:  "we're not going to tell you here how to find any components 
needed to validate the imported namespace."  So, the policy for finding 
the schema is external to the importing schema document.  That policy may 
depend on many factors other than the namespace name.  E.g., it could 
depend on the database column in which the instance to be validated is 
stored, it could depend on the application doing the validation (which 
might supply the schema, perhaps in the form of schema documents or 
perhaps not), and so on. 

In fact, I've always argued that xs:import without schemalocation is 
really just an early hint to tooling that there may be constructs in the 
form ref="ns:local" coming later, where ns binds to the imported 
namespace.  I think you'll find that, other than schemaLocation, the 
language would work exactly the same way if import were eliminated 
entirely.  It's just that you wouldn't be able to tell what namespaces 
were used until you'd parsed the entire schema document.  Rightly or 
wrongly (and I've worried about our choice since the day we made it), we 
decided that the added complexity and possibly confusion surrounding 
xs:import was offset by the easy ability for tools to easily find out 
which namespaces were referenced.  I don't think the intent was to say 
that the resolution could depend only on the namespace name. 


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Thursday, 14 September 2006 16:56:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:10 UTC