RE: Suggested guidelines for using local types. (was Re: Enlightenment via avoiding the T-word)

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

Jonathan,

> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net]
> Sent: Wednesday, September 05, 2001 11:11 AM
> To: Fuchs, Matthew; xml-dev@lists.xml.org
> Subject: Re: Suggested guidelines for using local types. (was Re:
> Enlightenment via avoiding the T-word)
> 
> 
> Matthew,
> 
> >
> > I think you mentioned at one point that you were on 
> vacation during the
> > start of this rather long and verbose thread.  The 
> discussion is entirely
> > about the treatment of local elements as defined by XML Schema.
> 
> I assume that the discussion regards the implications for XML Schema's
> "local elements" for _XML_ because if we aren't talking about 
> XML, then this
> is simply the wrong forum.
> 

Ah, but XML Schema is XML, although not all of it, so yes, whether they make
sense, and how others should be affected (or not) by them is legitimate.

> > If you read
> > the XSDL spec, you'll see it defines "local" and "global" 
> elements by the
> > context in which those elements are declared in a Schema - 
> either at the
> > root level or within a type - not where they appear in an 
> instance.  In
> > particular, the same local name may be used for an element 
> scoped locally
> to
> > a variety of different types, so in the context of XSDL, 
> the same local
> name
> > may refer to a variety of different elements - meaning 
> different structure
> > and different semantics (there's enough contention on the difference
> between
> > "same element" and "different element" to keep modal 
> logicians busy for a
> > decade at least).
> 
> Of course one define identical syntaxes with DTDs which don't 
> need to invoke
> such "local" and "global" differentiations. I wonder what the 
> real need for
> this complexity is?
> 

Actually, one can't define identical syntaxes with DTDs because I can
include your DTD in mine with a parameter entity, and then use you "local"
elements in any content models of my own devise.  That is explicitly not
possible with XSDL local elements.

> You see this really does have implications for XML because 
> the instance
> documents which are produced intending to be valid with 
> respect to some
> schema have element names which are defined by the schema. Indeed your
> suggestion that one might differentiate an XML Schema "local 
> element" from
> an XML Schema "global element" based on whether such an 
> element is either
> namespace qualified or not smacks of a sneak attack on XML itself.

Getting a little paranoid aren't we?  It's a "sneak attack on XML itself" to
suggest that one can use markup to guide processing?  As Len said recently
"the Web is just plumbing, not a lover"

> Particularly the practices which you argue for go against 
> what I consider
> XML namespace best practice, so again, this discussion is 
> hardly limited to
> XSDL "local types".
> 

What is the goal of best practices?  And why aren't they allowed to evolve?
Suppose I have a set of schemas with no local (as defined by XSDL) elements,
so all elements are in the namespace of the schema, and my partners and I
have been sending documents to each other mixing markup (validly) from these
schema, and we've all been using your best practices.  Now suppose we want
to add some local elements to a type in one of the schemas, and we'd like
not to break existing code built on current best practices (which assumes
every element is in a namespace).  Should these local elements be qualified
or unqualified, given that (as per the rec) they may have the same local
names as other local or global elements (again as define by XSDL)?  Please
explain you answer with reference implications for existing applications.
Please show how your answer doesn't violate the principle of least surprise
(or its corollary, early warning) and how (a goal of best practices) if your
choice does cause current applications to break, they break systematically -
and, in particular, don't do the wrong thing.

> > I hate to sound like a professor ("You haven't done your 
> reading!"), but
> you
> > might want to come up to speed on that aspect of this and 
> then see if what
> > I've written makes more sense.
> 
> I didn't buy the argument the first time around. Are you 
> suggesting that
> your position is so self evident that the only rational reason for
> disagreement is a lack of understanding?
> 

No.  However in your original post you said the following:

'Perhaps the complexity is produced by your introduction of these concepts
"global" and "local" element. To me, every element has context, and I am not
sure I need to make a distinction between "local" and "global" elements.
Unless its the document element every "x:name" element is the child of
something, correct?'

In this you impute the "introduction of these concepts 'global' and 'local'
element" to me.  And then in your last sentence you seem to confound "local"
with being the child of another element.  Since the concepts "global" and
"local" are those introduced in the text of the XSDL recommendation, and the
concept of local described there is not about whether an element is
contained within another, it seemed to me you were arguing against a
position I had not stated, and if you understood what I was actually talking
about, you might change your opinion.  I don't know if you've read the XSDL
rec, but you obviously haven't changed your opinion.

> My basic position is this: It is a best practice to design 
> document schemas
> so that the structure of the resulting documents is evident 
> from inspection
> of the documents themselves without requiring reference of the schema
> itself. (as much as is reasonably possible). 

Right - thank you for making my case for me.

For example HTML 
> processors are
> perfectly capable of processing HTML documents -- without 
> reading the HTML
> DTD each and every time the document is parsed --. Schemas 
> can be incredibly
> useful, particularly during the software development phase 
> i.e. assisting
> with the automatic generation of user interfaces, storage and 
> indexing of
> documents in databases, debugging, etc. but still, it is a 
> best practice not
> to needlessly rely on a scheme at every step in a production 
> system. Of
> course this is my viewpoint and YMMV.
> 

Precisely.  That's why you should not only make local elements unqualified
for now, but also insist on the Schema WG taking the other steps I've
specified in this thread.

> Back to XSDL, the entire point of using schemas is to design 
> XML document
> structures. XSDL "local types" have no reason to exist 
> otherwise. Certainly
> this discussion is about more than XSDL in isolation.
> 
> 
> 
> > >
> > > Shrug. I've never had to resort to namespaces to sort out
> > > similar issues in
> > > programs. e.g. C++.
> > >
> >
> > Because "real" programming languages have the treatment of 
> namespaces
> > integrated into the language in a smooth way.  XSDL does not.
> 
> XML and XSDL are not, nor are they intended to be, 
> "programming languages".
> Perhaps this is the big disconnect. Let's not design our XML/XSDL best
> practices toward the view of XML as a programming language!
> 

Yes, but SQL also doesn't have this problem!  And programming languages can
have very sophisticated data description languages embedded in them.  

> > > >
> > > > The global "name" now matches against the right template.
> > > The "person"
> > > > template matches against the right template.  And the 
> _local_ "name"
> > > doesn't
> > > > match the template for the global "name" because (tada!)
> > > it's not in the
> > > > right namespace.  Therefore it defaults to matching the
> > > default template -
> > > > just the behavior Rick wants (I think).
> > >
> > > Again, if the template does not blindly call
> > > <apply-templates> this isn't an
> > > issue.
> > >
> >
> > But why shouldn't the template blindly call 
> <apply-templates>?  Certainly
> > it's better to let people worry about their problem, not 
> XSDL's problems.
> >
> 
> People shouldn't blindly call apply-templates specifically to 
> avoid the
> problem you note above. If you want to invent "local 
> elements" in order to
> allow you to program XSLT in your own way, fine, but please 
> try not to foist
> this upon all of XML + Namespaces + Schema
> 

So, you still haven't read the XSDL rec have you?  Local elements are
already _in_ Schema.  The question is how to use them without breaking
everything else.  Or is being brittle a requirement of a "best practice"?

Matthew