Re: Language = Namespace. was: How namespace names might be used

At 16:23 2000 06 19 -0700, Tim Bray wrote:
>If we agreed that namespace names were just names, then we would have a
>basis for building a rough consensus.  But clearly some of us don't.
>If we agreed that they were something more, and had a pretty crisp 
>description of what that was, and that this was more important than the 
>original goal of naming, once again we could move forward.  But some of
>us either want to stay in the "just-names" space, and others aren't
>comfortable with "something more" without more details. 
>
>Inspiration, someone? -Tim

Do we have to decide this issue?  I was hoping not.

I was hoping to reduce the problem to one of defining a bunch
of string functions and so ignore all the angst-producing issues
about meaning and resolution and application use and such.

We need some function f that takes an ns-attrib string and
a base URI (in the RFC 2396 sense) string and returns a
namespace name:  f(ns-attrib,baseURI) -> nsn.  Possible
function definitions include:

  literal:     f(ns-attrib,baseURI) -> ns-attrib
  forbid:      f(ns-attrib,baseURI) -> ns-attrib
  absolutize:  f is defined by the algorithm in 5.2 of RFC 2396
                and the baseURI is determined by 5.1 of RFC 2396
  fixed-base:  f is defined by the algorithm in 5.2 of RFC 2396
                but the baseURI argument is ignored and a 
                constant base URI is used instead
 
Note that the "deprecate" option isn't really an option in
this sense.

Having decided the above function that gives us nsn's, then
for the purposes of the "unique attribute" issue, we need a
function that takes two nsn's and two local names and returns
a boolean "unique/non-unique" answer.  We haven't spent much
time on this function because I assume folks are okay with
the one described in the Namespace spec, and I hope we can
leave it that way.

Finally, with the above decisions, the Infoset spec will have
to decide which of the various things to surface in the infoset,
but that's not a discussion for this list at this time.

As far as all the rest of several dozen issues that have been
discussed on this list, I don't think we need to address them
to solve the current problem. 

paul

Received on Wednesday, 21 June 2000 16:55:17 UTC