Fw: Re: Namespace prefixes optional?

[Oren Ben-Kiki]

I'm hijacking this to the SML group. Nice idea, definitely not XML -> seems
like good potential SML material.

----- Original Message -----
From: <rev-bob at gotc.com>
To: xml-dev <xml-dev at ic.ac.uk>
Sent: Monday, January 10, 2000 18:57
Subject: re: Re: Namespace prefixes optional?


> > > That is, by defining "fragment" as belonging to namespace rbns, I am
defining the
> > > attributes of "fragment" and the children of "fragment" as belonging
to the same
> > > namespace by default.  With the "p" element, I declare that it belongs
to the htmlns
> > > namespace, along with (by default) its children and attributes.  With
the "b"
> > > element, for some reason, I need to attach an attribute from the
bubbans namespace
> > > - so I mark just that attribute as belonging to a different space.
When "p" closes, so
> > > does the htmlns fragment, and the default namespace reverts back to
rbns.
> > >
> > > Simple enough?
> >
> > Perhaps too simple. :-)
>
> Then perhaps I've hit the mark squarely.
>
> > In the event that you wanted to fragment your data further and the
original namespace
> > was significant in the new context, you would meed to obtain from the
higher level
> > element and make it explicit when you do the fragmentation.
>
> Why?  It's a really simple concept - whenever a child (element or
attribute) requires a
> namespace which is not the same as its parent's namespace, the child's
namespace must
> be explicitly noted.  That's the extent of the relationship - grandparents
and such are
> important only so far as defining the parent.  In other words, consider
another XHTML
> example:
>
> <htmlns:table align="center">
>   <tr><td><table>
>     <tr><td><rbns:name>
>     <first>Robert</first><htmlns:b>L.</b><last>Hood</last>
>     </name></td></tr>
>   </table></td></tr>
> </table>
>
> That name element is buried deep in layers of htmlns-code, but the only
concern is that
> the name tag does not reside in the same namespace as the td element which
contains it.
> Similarly, the bold-faced middle initial doesn't look at the preceding
code to say "I'm in
> the same namespace as the outermost table element," but instead just says
"I'm in the
> html namespace."  Each element can be understood with minimal code - just
know the
> parent's namespace, and know how to pass it along as the default for the
children.
> Containers and recursion work very well together, don't you think?  Once
the b element
> completes (pops), its temporary island of XHTML goes away, and the
previous default
> (rbns) resumes control.  Once that name element pops, the previous default
(which
> happens to be XHTML again) reasserts itself.
>
> Maybe I *did* make this too simple; you seem too eager to make it far more
complex
> than it really is.
>
> > I suppose the feeling was that you can create your data in the way that
you described,
> > then apply a simple tool to make the namespaces explicit,
>
> No, no, no!  No more tools required!  At all!  Say it with me: "A child
element inherits
> the namespace of its parent, unless otherwise specified.  An attribute
inherits the
> namespace of the element to which it belongs, unless otherwise specified."
Boom.
> Done.  Clear?
>
> > and that this was preferable to requiring the manipulation when the data
is being
> > fragmented.
>
> No, the feeling was that defining a default namespace via inheritance is
preferable to the
> endless debate about how:
>
> <htmlns:a href="http://www.gotc.com">
>
> compares to:
>
> <htmlns:a htmlns:href="http://www.gotc.com">
>
> With the inheritance model I've laid out, these are explicitly identical -
because in the
> first example, href *inherits* its namespace from a, which is defined as
being in the
> htmlns namespace.  A namespace-compliant parser would hit the htmlns:a
element, note
> it as an a element which belongs in the htmlns space, and treat all the
children and
> attributes of that element as defaulting to the htmlns space.  The href
attribute is next in
> line - no explicit namespace, so it belongs to the default - htmlns.  When
the a element
> closes, so does its domain of inheritance; the parent has no more
children, so it cannot
> pass on its namespace to anything else.
>
> The only thing I'm not really sure about with this model is whether the
namespace
> should be explicitly stated on the closing tags - ie., whether my
nested-table example
> should really read like so:
>
> <htmlns:table align="center">
>   <tr><td><table>
>     <tr><td><rbns:name>
>     <first>Robert</first><htmlns:b>L.</htmlns:b><last>Hood</last>
>     </rbns:name></td></tr>
>   </table></td></tr>
> </htmlns:table>
>
> I can see arguments both ways - on the one hand, a non-namespace parser
will treat
> htmlns:table and table as different elements, and thus should report an
improper nesting
> error (right?), so adding the namespace to the closing tag avoids that and
also makes the
> inheritance domain a bit clearer to someone trying to read the code.  I
could live with
> that, I guess....
>
> > >  Rev. Robert L. Hood  | http://rev-bob.gotc.com/
> >
> > I'm guessing you've been quiet because Christmas is your busy
period...:-)
>
> No, just haven't had a lot to say.  That, and I'm in the middle of moving
*and*
> preparing to attend a science fiction convention this weekend....  (I get
to interview
> Bruce Sterling!  Woo-hoo!)
>
>
>
>  Rev. Robert L. Hood  | http://rev-bob.gotc.com/
>   Get Off The Cross!  | http://www.gotc.com/
>
> Download NeoPlanet at http://www.neoplanet.com
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)