[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespaces, schemas, Simon's filters.
- From: Peter Piatko <piatko@research.telcordia.com>
- To: Ronald Bourret <rpbourret@rpbourret.com>, xml-dev@lists.xml.org
- Date: Tue, 28 Aug 2001 12:32:20 -0400
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@rpbourret.com>
To: <xml-dev@lists.xml.org>
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>
>
>
- References:
- Re: Namespaces, schemas, Simon's filters.
- From: Ronald Bourret <rpbourret@rpbourret.com>
- RE: Namespaces, schemas, Simon's filters.
- From: Tim Bray <tbray@textuality.com>
- Re: Namespaces, schemas, Simon's filters.
- From: Peter Piatko <piatko@research.telcordia.com>
- Re: Namespaces, schemas, Simon's filters.
- From: Ronald Bourret <rpbourret@rpbourret.com>
- Re: Namespaces, schemas, Simon's filters.
- From: Peter Piatko <piatko@research.telcordia.com>
- Re: Namespaces, schemas, Simon's filters.
- From: Ronald Bourret <rpbourret@rpbourret.com>