[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace: what's the correct usage?
- From: Joel Rees <email@example.com>
- To: Eddie Robertsson <firstname.lastname@example.org>
- Date: Mon, 21 May 2001 14:51:44 +0900
From a half-crazed newbie out in right field --
I was going to suggest that qualified nested names ought to mean something
entirely different from unqualified nested names. For example, in my mind,
<xsl:if> should instantiate a particular node as a particular xsl object,
where a plain <if> in the same place should instantiate an object of, uhm,
well, a piece of what is being instantiated, which would be whatever one
would otherwise expect at that node.
I, being used to nested contexts for some reason, would see nothing at all
unnatural in inheriting the expectation from the most recent ancestor node.
In fact, in my perception of perception, this is a necessary aspect of
perception itself. To back up my argument of perception, I was going to
offer the principle of inheritance in object-oriented languages, and the
corollary between a context-free grammar and a two-stack machine.
(I haven't kept up with this, but has anyone ever proven whether two stacks
is insufficient for un-restricted grammars?)
Now, Eddie, you point out to me that many people would deny my perception of
perception. Even if I am right and they themselves are managing their
perceptions through nested contexts, they may be unwilling to recognize it,
or even to understand what I am talking about. Then my recognizer branches
out and I consider multiple inheritance and my former manager who swore that
CoBOL could do anything C could because a procedural language is a
So I offer my two cents. But when I stretch forth my hand, behold, it is
============================XML as Best Solution===
Joel Rees $B%j!<%9!!%8%g%(%k(B
Media Fusion Co.,Ltd. $B3t<02qhttp://www.mediafusion.co.jp
Iwaku Eddie Robertsson <email@example.com>
> > Sorry. I meant that an explanation along with this line is probably more
> > adequate for my "XML Schema: DOs and DON'Ts", as the reason of why one
> > should avoid unqualified local elements.
> Before this discussion comes to an end (if it ever will...) I think I'll
add my 2
> cents worth. I think we can agree that there is no "correct" way of using
> namespaces however both Simon and Kohsuke make a very good point that
> namespaces the way Martin does is confusing for people new to namespaces.
> just spent 4 months writing a 2 day course on XML Schema (No it's not a
> comprehensive course that explains every detail). The course is intended
> people with knowledge in XML and XML Namespaces. I start off with a short
> of DTDs and Namespaces before going into XML Schema. Thus far I've only
> session so this may not be very significant but what I expected to spend
> was the more complex issues in XML Schema (complex type derivation,
> elements etc.) but I was surprised to see that the attendants understood
> easily. Instead I had to spend a long time on the Namespace review and
> default namespace declarations. As long as every element was prefixed it
> but default namespace declarations caused confusion. I had planned to
> meaning of the elementFormDefault attribute but I ended up telling them to
> set elementFormDefault="qualified" in their schemas (at least in the
> because there was no way I could explain it to them. I also suggested that
> always should use explicit namespace declaration because it is less
> So, even though Martins use of namespaces is perfectly valid maybe we
> careful with it's use in consideration of XML developers just beginning to
> understand namespaces.