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

Re: XML Schema: DOs and DON'Ts

  • From: Kohsuke KAWAGUCHI <kohsukekawaguchi@y...>
  • To: Martin Gudgin <marting@d...>, xml-dev@l...
  • Date: Wed, 16 May 2001 18:40:40 -0700

override xml schema attribute

> OK, perfectly valid for that use case but that is *not* the use case you
> give in your document. The reason you give for using attribute groups is
> because you don't think people should use global attribute declarations.

OK, now I understand your point better. Let me go back to your original
question.

> 4.    Regarding your comment about attribute groups, why not just use a
> local attribute declaration? That *is* what you get anyway despite the
> syntactic sugar that, it would seem, makes you think otherwise.

As you said, a local attribute declaration will solve the problem I
depicted. But why do you bother learning that attributes can be used
locally, when you can achieve the same effect by using attribute groups?

And you need attribute groups anyway.

It's just that I didn't feel the necessity to mention that attributes
can be declared locally.

Maybe I can even argue that local attributes are bad because you can't
reuse or override them. (maybe)




> > Again I'd appreciate if you would tell me why you wrote
> >
> > <foo:person xmlns:foo="http://best.practice.com">
> >   <familyName> KAWAGUCHI </familyName>
> >   <lastName> Kohsuke </lastName>
> > </foo:person>
> >
> > instead of
> >
> > <person xmlns="http://best.practice.com">
> >   <familyName> KAWAGUCHI </familyName>
> >   <lastName> Kohsuke </lastName>
> > </person>
> 
> Perhaps because I'm mapping from the following Java type;
> 
> package best.practice.com;
> 
> public class person
> {
>     String familyName;
>     String lastName;
> }
> 
> I think a lot of people that are using XML for something other than document
> markup may well end up going this way.

I think you don't answer my question. There is no reason that data
binding software can't support my way of using namespace. It's not a
matter of document or data. It's, well, a matter of philosophy or
something.

What is the reason *not* to qualify lastName and firstName (ouch, I just
find that familyName==lastName .... )?



And if you don't qualify familyName, then how can you distinguish that familyName
element from this familyName element?

<x:mafiaCatalog xmlns:x="http://some.department.of.fbi.gov">
  <familyName> KAWAGUCHI </familyName>
  <area> Chicago </area>
  <description>
     ....
  </description>
</x:mafiaCatalog>

In the concept of XML namespace, I believe they are strictly identical
elements because their namespace URI and their local name are the same.
Why can you justify that such a mixture is OK if you can tell the
difference from its ancestor?



> That's easy :-) *Always* put xmlns='' on any qualified element;

You are right. I found the same technique described in the spec.



regards,
----------------------
K.Kawaguchi
E-Mail: kohsukekawaguchi@y...


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.