[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Fw: Re: Namespace prefixes optional?

  • From: "Oren Ben-Kiki" <oren@c...>
  • To: "sml-dev" <sml-dev@e...>
  • Date: Mon, 10 Jan 2000 23:00:15 +0200

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

----- Original Message -----
From: <rev-bob@g...>
To: xml-dev <xml-dev@i...>
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@i...
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@i... the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo@i... the following
message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@i...)
>


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



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.