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

[Jonathan Borden <jborden@mediaone.net>]

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

Perhaps you can understand that the guidelines you are proposing, and way of
viewing _XML_ elements as either "local" or "global" is not widely accepted.
At the very least, I strongly disagree with this guideline. Of course these
terms are defined in XSDL, but I see such definitions purely as an artifact
of XSDL, or more properly as pure syntactic sugar. Specifically, for any
grammar you define in XSDL using local and global elements, I imagine that
an equivalent grammar can be defined in, say, RELAXNG, which doesn't make
use of the terms "local" or "global" element.

As I've tried to say, and as James Clark has more capably stated,
essentially every element in a grammar is somehow constrained by its
context, so that if we wish to use these terms in a meaningful sense, we
ought not arbitrarily classify an element as either "local" or "global" but
rather by some degree of context dependency.

In terms of paranoia, hardly. I submit that many of the initial promises of
XML are as yet largely unfulfilled, and I at least want to see an "XML"
(including accepted associated specifications) which remains as simple as
possible. I have yet to see a truly convincing usage of the _terms_ local
vs. global element, which is in any way worth their cognitive complexity --
I do not mean to argue that the ability to locally define elements is not
_quite_ useful, indeed it is, yet having the ability to do this does not
equate with the distinctions that _you_ draw in your arguments, which lead
to the guidelines _you_ propose.

I am annoyed that you suggest that my view is one based on a lack of reading
of the XML Schema specification. May I suggest that you re-read this thread
from the beginning, and perhaps gain an appreciation of how convoluted these
arguments are. I am concerned that "XML" is becoming too complicated, and do
not consider this fear  unhealthy paranoia.

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

Matt, a name is a name. Trivially I could place whatever "local" elements I
wish into a special namespace e.g. http://example.org/local which would
loudly and clearly explain the indended "meaning" of the element names.
There ought be nothing special about unqualified element names.

What about XML grammars that do not use namespaces at all? Do you suggest
that people _must_ use namespaces in order to solve this so called fragility
problem. I imagine there are scores of outstanding SGML developers that have
solved such problems.

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

Particularly in a document that uses a single _unprefixed_ namespace, it
will be immediately obvious which elements are in which namespace by
inspecting the prefix. That is the principle of least surprise requires that
each namespace be associated with a single prefix (considering no prefix as
"an empty" prefix)
>
> > > 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.

I have no idea who is responsible for _creating_ the XSDL concept. You are
introducing the concept into the XML-DEV forum. At the very least, you
appear to be the individual most loudly and ferverently arguing that "local
elements" ought be unqualified.

 And then in your last sentence you seem to confound "local"
> with being the child of another element.

Can a "local element" be the root element of a document? Otherwise they are
all children of other elements.

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

 XSDL constrains the occurance of "local" elements based on their parents,
no?

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

Perhaps what you seem to be saying is not what you are trying to say. What I
am saying that that such concepts (local element) can be _equivalently_
explained using e.g. RELAXNG patterns or XDuce types. Is there something I
am missing?

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

I don't follow. Sorry for being dense.

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

And RDF treats all properties as first class objects...

Really my objection is quite simple (I think):

I like having namespace qualified documents whose elements are unprefixed (I
just looks nicer) ... for example XHTML. I don't want to create confusion
between such elements and unqialified elements. That's all.

Jonathan