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

Re: Namespaces, schemas, Simon's filters.

  • From: Peter Piatko <piatko@r...>
  • To: Ronald Bourret <rpbourret@r...>, xml-dev@l...
  • Date: Tue, 28 Aug 2001 12:32:20 -0400

namespaces schemas
I *sort of* agree with you.  The Namespace just introduces a mechanism to
generate ulabels (as Tim calls them)---it doesn't say how they should be
interpreted.  (Somehow, given this viewpoint, this makes me feel that
Appendix A of the rec is a bit misleading, even if it is non-normative.)
OTOH, I feel that having no interpretation of what a namespace is will
inevitably lead to interoperability problems, because we'll all come up with
our own interpretations, none of which will be explicitly described
anywhere.

So far on this list I've seen 2, well 2.5, interpretations:

(1) A ulabel should have a 1-1 mapping to its "meaning" (a word I am being
intentionally vague about).

(1.5) Believes in (1) and introduces local elements in the hopes of some
modularity.

(2) A ulabel can map to multiple meanings.  Other mechanisms (context, a
schema, calling up someone on the phone) might also be employed to fully
disambiguate the meaning.

When groups with different interpretations meet, sparks fly, harsh words are
spoken, and Simon creates a filter to bridge the semantic gap.  ;-)  Maybe
such filters are the best we can hope for.

Thanks,

Peter

----- Original Message -----
From: "Ronald Bourret" <rpbourret@r...>
To: <xml-dev@l...>
Sent: Tuesday, August 28, 2001 2:22 AM
Subject: Re: Namespaces, schemas, Simon's filters.


> Peter Piatko wrote:
> > I think it is pretty clear that the syntactic sugar of the Namespace rec
> > doesn't handle hierarchies all that well, and that Per-Element-Type
> > partitions introduce such hierarchies (of at least one level anyway).
So I
> > feel that the options are (a) enhance the syntax or (b) simplify (i.e.
> > flatten) the interpretation of what namespaces are.  The current
situation
> > is just confusing.
>
> Agreed, although it is mostly confusing because we keep trying to impose
> things on namespaces that just aren't there. I've many a mini-career
> trying to debunk these and I still get tripped up...

> > Option (b) implies that an identifier might map to multiple types.  I
think
> > the question boils down whether this ok or not.
>
> In the end, I think you have to allow it. My gut tells me that the
> alternative could get quite nasty. Besides, one of the nice things about
> XML is that it does let you do your own thing, even if that thing isn't
> always the best thing to do.
>
> -- Ron
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>


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.