Re: Irony heaped on irony

So, versioning has also been tossed into the accretive heap of
problems that namespaces are _newly_ expected to address?

Contrary to the REC, which lists only identification?

The XML namespaces spec did not list versioning of the things
as a problem that it needed to solve.  IMHO, that's wise ...
given how many solutions to versioning problems are currently in
widespread use.

Seems to me that the better approach is to come up with a separate
NOTE about policies (which is definitely plural!!) that can be used
to address various versioning issues, rather than trying to rewrite
history and the namespace REC.  Yes, a NOTE ... since it's impossible
to get any true industry consensus on versioning.  There are multiple
problems (interrelated) under that rubric.  RECcommending only one of
the many solutions would tilt the WWW to only solving some of those
problems.  IMHO, adopting such platform biases would be very unwise.

For example, what would be a "compatible" change to a namespace?
Clearly, adding a "you can ignore this" element or attribute is one.
In your "xhtml:dwim" example, if "dwim" is ignorable, the problem
you allude to doesn't exist.  If it's not ignorable, likely it should
not be in the XHTML namespace.


I'll not address technical issues about the two solutions you mention
here, except to point out that the Java solution addresses what can
be called "macro" versioning issues (sets of interface changes, as
well as behavioral changes such as bugfixes), while the COM solution
you refer to is more "micro" (new interface == new UUID).

Both are augmented by various solutions for the other types of issue;
Java can use (and detect) new interfaces (Swing, extensions, ...)
with old platforms if they're properly installed, and I can't count
the number of "needs IE5" or "doesn't work on Win2K" constraints I've
seen (despite having COM underneath).

In short, the extremes you noted are barely the beginning of the story!

Also, historically both those solutions predate the technologies you've
identified them with, which I expect you knew -- I just don't like to
see this discussion come off as a "Java vs. COM" debate, since some
people have taken sides based purely on such (mis)characterizations.

- Dave


----- Original Message -----
From: Dan Connolly <connolly@w3.org>
To: David Megginson <david@megginson.com>
Cc: <xml-uri@w3.org>
Sent: Sunday, May 21, 2000 5:48 AM
Subject: Re: Irony heaped on irony


> [I missed this when it was first sent...]
>
> David Megginson wrote in his message of Thu, 18 May 2000 16:44:04 -0400
> (EDT):
> > Dan Connolly writes:
> >
> >  > >  The schema for schemas (and others) should reference an XML
> >  > > schema for the xml: Namespace using the xsi:schemaLocation
> >  > > attribute, as in
> >  > >
> >  > >   xsi:schemaLocation="http://www.w3.org/XML/1998/namespace
> >  > >
http://www.w3.org/XML/Schemas/xmlschema-20000518.xsd"
> >  >
> >  > Why? Why use schemaLocation when there's no need to?
> >
> > I'm too tired to rehash this whole debate for the third (or fourth?)
> > time -- we've fought it too many times already, for nearly two years,
>
> This name/address/identifier discussion goes back longer than that...
> I joined it in 1991. But it's central to the architecture that
> some of us in W3C have been trying to set up since at least 1995.
>
> > and in general, the W3C WGs have done the right thing in the end (as
> > the Schema WG did with xsi:schemaLocation and as the XHTML WG did with
> > the single Namespace URI)
>
> Or the wrong thing, depending on your perspective.
>
> We have compromised on this issue in order to get a few specs
> out the door, thinking that we can do it better next time. But
> it's clear that it's getting worse, not better. So we're trying
> to see if we can actually address the issue to the satisfaction
> of all concerned at this point, rather than working around it any more.
>
> > -- so I'll summarize my position, then drop
> > out of the debate and let those who are less jaded continue it.
>
> I read your summary and I don't find it compelling and I'd
> like to discuss it further. I can certainly understand your reluctance
> to commit to participating in all the discussion, but
> if we come to any conclusion, I hope that you'll be involved.
>
> > Many people (not Dan, or Tim B-L, but many of the rest of us) consider
> > XML namespaces to be conceptually equivalent to C++ namespaces or Java
> > or Perl package names -- that is, they are unique identifiers that
> > serve exactly two roles:
> >
> >   1. group elements and attributes with different local names into a
> >      single collection about which general statements may usefully be
> >      made (i.e. "if a processor finds an unrecognized attribute in the
> >      X Namespace, it should ignore it"); and
> >
> >   2. disambiguate elements and attributes with the same local names.
> >
> > That's it.  Period.
>
> How ironic! Java and Perl package names are both used to look
> up source code.
>
>
> > (Now, it happens that both of these functions provide a useful service
> > to schemas: (1) allows schemas to make general rules about a related
> > collection of element and attribute names, and (2) allows schemas to
> > be applied to documents with components defined by multiple
> > authorities.  No one, I think, disagrees with either of these
> > benefits.)
> >
> > In Perl or Java, package names do not change with each new release:
> > Java2 still uses the java.util package name just like Java 1.0 and
> > Java 1.1 did, even though the package's contents have changed
> > considerably.
>
> There are advantages and disadvantages to this... Java software
> is often labelled with out-of-band instructions on resolving
> Java package names ala "you need at least JDK 1.2 to compile
> this package" and such. They make it more convenient to
> install version 1.1 in place of version 1.0 on some machine
> and continue to use the code that was compiled on that
> machine against 1.0, but they make it less convenient to
> coordinate releases on a global scale.
>
> COM takes the other approach... they provide compile-time
> friendly aliases for UUIDs, but released code references
> the globally scoped UUIDs. And the COM design recognizes
> that code built against 1.1 libraries (using, e.g.
> function OpenEx from interface Syslib) might in fact
> be installed on a machine with 1.0 libraries (where inteface
> Syslib only has Open, not OpenEx). COM provides different
> global names for Syslib version 1.0 and syslib version 1.1
> so that this code won't crash by trying to call a
> non-existent OpenEx function in the 1.0 library.
>
> Lest you should argue that this doesn't apply to markup
> languages like XHTML, consider the case of a document
> that depends on the XHTML version 6.3 "dwim" element...
> the author checks the spec in 2003, and sure enough, dwim
> is in the XHTML namespace. Then he ships his document
> to a system WizDoc that claimed, way back in 2001, to
> support the XHTML namespace. But WizDoc doesn't support
> dwim. So the author has to label his document ala
> "requires support for version 6.3 of the XHTML namespace"
> using an ad-hoc labelling mechanism that works only
> with a human in the loop.
>
> Perhaps we expect this to be rare in the future usage
> of XHTML, and we accept the cost in order to get
> the benefit of being able to use the same XSLT
> script across the next few revisions of XHTML.
>
> But that doesn't mean Java package name style versioning
> is right and COM interface style versioning is wrong.
> It just means that each is more cost-effective than
> the other in some cases.
>
> RDF Schemas use the COM-style naming/versioning policy.
> XHTML and XSLT use Java-style naming/versioning policy.
>
>
> >  Likewise, Namespace URIs should not change with each
> > new revision: if or when XML 3.0 comes out, the xml: prefix should
> > still be mapped to the http://www.w3.org/XML/1998/namespace URI, so
> > that it's easy for software to recognize it.
>
> Maybe... or maybe it'll be lest costly to use a different
> namespace URI for new versions, so that software that
> uses the old/present (1998) namespace URI doesn't get
> any surprises.
>
> In the particular case of the xml: namespace, I think it's
> more likely that you're right... it'll be easier to
> keep it bound to the same namespace URI,
> and folks will just have to stay tuned to that URI to see
> how the namespace changes over time.
>
> > While Namespace URIs should be stable, schemas obviously need to
> > evolve.  It would be very dangerous silently to update the schema at
> > http://www.w3.org/XML/1998/namespace if XML 2.0 adds another xml:
> > attribute, since it would change the meaning of every schema that
> > referenced that one; on the other hand, it would be disastrous for XML
> > 2.0 processors to use a *different* Namespace URI for the xml: prefix,
> > since the millions of lines of code that had a hard-coded dependency
> > on the old one would break.
>
> Hang on... you can't have your cake and eat it too... either (a) the
> http://www.w3.org/XML/1998/namespace namespace may change over time,
> in which case having the meaning of every schema that references
> http://www.w3.org/XML/1998/namespace change when
> http://www.w3.org/XML/1998/namespace is updated is exactly what
> is intended, or (b) the http://www.w3.org/XML/1998/namespace does
> *not* change over time, and we'll need a new URI when
> we define a new xml:blort attribute in XML 2.0, and XML 2.0
> processors will have to recognize the new URI as well as the
> old one.
>
>
> > The solution to this problem is, or should be obvious.  We have two
> > fundamentally different kinds of things -- the Namespace (or package
> > name, if you prefer), which should change rarely, if at all, and the
> > schema, which may change frequently, so each should be referenced with
> > a different mechanism.
>
> I agree that there's an obvious tension between wanting to exploit
> references to an old namespace name on the one hand and wanting to be
> able
> to update the description of the namespace at will on the other hand,
> but
> that's the nature of distributed information systems. Sure, we provide
> schemaLocation for times when it's not feasible to use the same URI
> both for looking up a schema and matching other references to the
> namespace, but I don't see why this should preclude using the
> same URI for both when it is feasible.
>
> I disagree that using two URIs is the obvious solution in all,
> or even the majority of cases.
>
> > Using (or even allowing) the same mechanism for referring to both will
> > simply encourage confusion and the worse practice (I know that RDF
> > already did so, but since virtually no one is using RDF schemas in
> > real-world apps, that may not be much of a problem).
>
> Virtually no one is using schemas to mix vocabularies at all. Of
> those that are mixing vocabularies, RDF Schemas is one of the
> most popular technologies, from what I can see
> (cf http://www.w3.org/RDF/#projects).
>
>
> > XML schemas should allow *only* the xsi:schemaLocation attribute and
> > no other mechanism,
>
> I accept this as your opinion, but it's not a conclusion that
> I'm compelled to accept on the basis of the argument you've
> presented.
>
> > and the WG should set the example by using that
> > attribute itself. If somebody insists on sticking a schema at the end
> > of a Namespace URI, it's hard to stop them, but at least we can point
> > at the practice as very sloppy engineering.
>
> I disagree. I think that in the vast majority of cases, it
> will be simpler for all concerned, not to mention immensely
> more powerful, to use the same URI for
> a namespace and a schema that describes/defines it.
>
>

Received on Friday, 26 May 2000 06:14:03 UTC