RE: Namespaces, schemas, Simon's filters.

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Tim,

Uh, once again the parallel to the original namespace discussion is so
revealing.  As I recall, the same arguments were made about the linking from
labels to namespaces - we could have stuck "namespace-pointer attributes" on
every element designating what namespace it should go in.  However,
providing a 1-1 map from labels to namespaces was considered crucial, so now
the labels themselves have been expanded to include the namespace.  Do you
think that was an error, and we should have adapted architectural forms?

> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com]
> Sent: Wednesday, August 29, 2001 11:53 AM
> To: xml-dev@lists.xml.org
> Subject: RE: Namespaces, schemas, Simon's filters.
> 
> 
> At 11:12 AM 29/08/01 -0700, Fuchs, Matthew wrote:
> >One doesn't really need any new syntax.  If we consider 
> complexTypes as
> >introducing a new namespace (which we're perfectly free to 
> do - the NS rec
> >doesn't say anything about how you create or name a 
> namespace, nor much
> >about what a namespace is) then xsi:type is an attribute 
> that says "the
> >default namespace within this element is the namespace created by the
> >complexType with this name".  That's it.
> 
> Suppose I believe that it's crucially important to be able to map 1-1 
> from labels to schema definitions (I don't, although Rick & Matt have 
> argued convincingly that it's good practice).  Suppose I believe that 
> the way to accomplish this mapping is via the labels themselves (I 
> don't; I think decorating the instance with definition-pointer 
> attributes - from a different namespace, natch - is the way to go).
> 
> If I believed those things, I'd be violently against tying namespace 
> creation to any particular schema language.  

That's not at all what I'm saying.  Right now an XSDL schema "creates" a
namespace with the targetNamespace attribute on the <schema> element (one
can argue over "create", but it certainly is an assertion that the namespace
exists) and all top-level elements declared in the schema are in it.
Likewise, one can consider the creation of a complexType as likewise
creating a namespace (or asserting the existence of a namespace) whose name
is the concatenation of the enclosing namespace and the local name of the
complexType (exact syntax open to discussion) and all elements declared
immediately within it are in that namespace.  This allows the schema
designer to use XSDL syntax to assert the existence of some set of
namespaces, and place his elements within them.

> Matt is correct that the 
> NS rec says nothing about how you "create" a namespace, it just tells 
> you how to put elements and attributes in them.  If what is 
> required is
> a new way to put markup in namespaces, we'd need a generalized 
> interface for doing this that an XSDL processor or any other software
> has access to.  I also think that it's pretty important that 
> in general, 
> applications of different classes, upon reading a document, all agree 
> what namespaces pieces of markup are in.  At the moment, the only
> way I can see to accomplish this is by putting the namespace syntax 
> right there in the instance. -Tim
> 

I agree.  The truth is, if people do as I've suggested, we don't actually
need _any_ new mechanism, although some new mechanism would be convenient.
If we choose to treat complexTypes as namespaces, and in your schema you've
declared local elements as being unqualified (not in a namespace) which
means 1) they're unprefixed in the instance and 2) they're not in the scope
of a default namespace declaration, then all you're doing is putting
previously unqualified elements in a previously non-existent namespace.  You
can immediately update all your instances by adding default namespace
attributes to the appropriate elements.  If you've already put your local
elements into the schema namespace, then adapting is much more difficult.
Likewise, I suspect that updating applications is much easier in the former
scenario than the latter.  So there's no _need_ for new mechanism.

However, it has been argued that a serious lacuna in the original NS rec is
the lack of an attribute to specify a namespace that applies only to the
_content_ of the current element, not the element itself.  Let's call it
xmlcont for the moment.  Having such a thing would be very convenient, both
for validating and non-validating applications.  For example, if I'm
inserting in one element content from another, with xmlcont I don't need to
worry about prefix collisions, eg:

Source:
<a:foo xmlns:a="foo">
  <a:e1/>
  <a:e2/>
</a:foo>

Target:

<a:baz/>
where a is defined somewhere above.

Result:

<a:foo xmlcont:a="foo">
  <a:e1/>
  <a:e2/>
</a:foo>

Here I don't need to worry about prefixes and namespaces in the target
document, as this a prefix only applies to the content I've moved over.

So one could argue for the general relevance of such a thing without any
discussion of XSDL, and one could ask what the original editors were smoking
that they didn't put this feature in (but I won't do that because it hadn't
occurred to me at the time anyway).  But suppose we go a little farther with
considering complexTypes as namespaces and realize that, since they have a
content model, they're really both - a namespace with a content model.  Then
we could say a validating processor, when it sees a reference to a namespace
with a content model, validates against that content model as well as
putting things in the right namespace, and a non-validating processor, just
puts things in the right namespace.  Then we get rid of xsi:type because
xmlcont does the same job but isn't as tied to XSDL.

This is just one solution among others I've considered.  It's probably the
most friendly to the whole breadth of XML, but there are other.  However,
getting back to the root of this whole discussion, it requires keeping local
elements unqualified for the nonce.

Matthew