Fw: Re: Namespace prefixes optional?
oren at capella.co.il
Mon Jan 10 21:13:17 GMT 2000
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
> > > 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
> > > element, for some reason, I need to attach an attribute from the
> > > - 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
> > >
> > > 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
> > was significant in the new context, you would meed to obtain from the
> > 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
> 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
> <htmlns:table align="center">
> 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
> 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
> parent's namespace, and know how to pass it along as the default for the
> 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
> (rbns) resumes control. Once that name element pops, the previous default
> happens to be XHTML again) reasserts itself.
> Maybe I *did* make this too simple; you seem too eager to make it far more
> than it really is.
> > I suppose the feeling was that you can create your data in the way that
> > 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
> the namespace of its parent, unless otherwise specified. An attribute
> namespace of the element to which it belongs, unless otherwise specified."
> Done. Clear?
> > and that this was preferable to requiring the manipulation when the data
> > 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
> it as an a element which belongs in the htmlns space, and treat all the
> 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
> should be explicitly stated on the closing tags - ie., whether my
> should really read like so:
> <htmlns:table align="center">
> I can see arguments both ways - on the one hand, a non-namespace parser
> htmlns:table and table as different elements, and thus should report an
> 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
> No, just haven't had a lot to say. That, and I'm in the middle of moving
> preparing to attend a science fiction convention this weekend.... (I get
> 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
> 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
> 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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev