Subject: namespaced linking extensibility - some problems in practice

From: Eric Scheid <[email-masked]>
Date: Thu, 21 Oct 2004 21:09:49 +1000

paraphrasing... it's been proposed to use external modules for linking
extensibility, which would look something like this:

    <ns1:elementfoo
            xmlns:ns1="http://example.org/foo"
            atom:href="..." .../>

with either the URI of the names space declaration being representative of
the relationship involved, or the namespace+elementname being so. This
wasn't really clear in the discussions to date, being handwaved more or
less. (if someone did explain this, please forgive me - I plead too many
emails)

Resigned to the thought that this might be the way we will go, I've been
playing with some examples in an attempt to understand it better. Most if
not all examples on the list so far have been expressed in generic form, and
not attempts at using a known external module or known relationship type
(eg. dublin core).

So ... Dublin Core has a relationship type of 'isReplacedBy', one which an
atom agent might find interesting enough to do stuff with (other than simply
render it as a human-clickable link) ...

Turns out xlink has an 'arcrole' attribute, which is analogous to @rel.

Thus, a 'DC.isReplacedBy' link might be expressed as

    <xlink:link xmlns:xlink="http://www.w3.org/TR/1999/xlink"
        xlink:type="simple"
        xlink:arcrole="http://purl.org/DC/1.0/terms/isReplacedBy"
        xlink:href="URI-to-resource"
        atom:href="URI-to-resource"
        />

Meanwhile, some other publisher might want to express a link using the same
relationship, but instead uses this form:

    <xhtml:link xmlns:xhtml="http://www.w3.org/1999/xhtml"
        xhtml:rel="DC.isReplacedBy"
        xhtml:href="URI-to-resource"
        atom:href="URI-to-resource"
        />

Then a third publisher decides to express the same thing this way:

    <dcterms:isReplacedBy xmlns:dcterms="http://purl.org/DC/1.0/terms/"
        atom:href="URI-to-resource">URI-to-resource</dcterms:isReplacedBy>

And a fourth publisher does this (and why not?):

    <html:a xmlns:html="http://www.w3.org/TR/REC-html40"
        html:rel="DC.isReplacedBy"
        html:href="URI-to-resource"
        atom:href="URI-to-resource">title-of-resource</html:a>

Now we have four ways of expressing a link with a well defined relationship,
but no easy way of detecting they are the same without first recognising all
four forms. Undoubtedly there might be yet more ways of expressing the same
thing ... topic maps can be expressed in XML, for example.

There is no defence against perversity, we know that. However if one
publisher wants to re-use their investment in using DC XML, while another
drinks the xlink koolaid ... that's not perversity.

That¹s a problem. 

e.

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 21 Oct 2004 08:58:30 -0400

I've followed this road before:

    http://bitworking.org/news/Not_Invented_Here

In that article I link to two example feeds, one using
the current syntax[1] and the other re-using as many
other XML vocabularies as possible[2]:

[1] http://bitworking.org/projects/atom/examples/original.atom.html
[2] http://bitworking.org/projects/atom/examples/reuse.atom.html

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 21 Oct 2004 06:54:31 -0700 (PDT)

Changing the title since this isn't about linking
specifically. 

What you are pointing out is that if people are
allowed to use namespaced extensions, it is likely
that they might use different extensions for
expressing the same concept. We have this in RSS today
with the various content modules ( content:encoded &
xhtml:body, dc:author & dc:creator, etc). This applies
to all protocols and markup formats that allow
extensibility in a decentralized manner. 

The only way to prevent this is to disallow
decentralized extensibility. 

--- Eric Scheid <[email-masked]> wrote:

>     <xlink:link
> xmlns:xlink="http://www.w3.org/TR/1999/xlink"
>         xlink:type="simple"
>        
>
>     <xhtml:link
> xmlns:xhtml="http://www.w3.org/1999/xhtml"
>     <dcterms:isReplacedBy
> xmlns:dcterms="http://purl.org/DC/1.0/terms/"
>        
>
>     <html:a
> xmlns:html="http://www.w3.org/TR/REC-html40"
> drinks the xlink koolaid ... that's not perversity.

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Danny Ayers <[email-masked]>
Date: Thu, 21 Oct 2004 18:05:46 +0200

> decentralized extensibility.

True, and I'm sure you'd agree there is some cost associated with such
duplication. But that doesn't make decentralized extensibility any
less desirable, and there are ways of minimising the potential for
duplication and offsetting the cost should it occur.

Duplication can be minimised by constraining the extensibility in such
a way that there are fewer ways of saying the same thing. XML does
this at the syntax level with its definition of well-formedness and
differentiation between things like elements and PIs. It's also
possible to define a higher-level language in which the extensions can
be expressed - this doesn't actually have to be a particularly
sophisticated language, merely an association between certain syntax
patterns and their interpretations within a logical data model and/or
a processing model. XSLT's extensibility is a good example.

The cost of duplication can be reduced by having a way of expressing
that different constructs are equivalent. There's another simple
example with XSLT - you can state that data expressed in format X on
applying the transformation becomes the same as data expressed in
format Y. This again is operating at the syntax level, but useful
statements of equivalence can be made at the semantic level by using
languages like OWL, e.g.
rss:item owl:sameClassAs atom:entry.

I think it's worth noting that minimisation of duplication as
described here and a facility for expressing equivalence are available
in RSS 1.0, both through its extension mechanism.

Cheers,
Danny.

PS. dc:author??

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 21 Oct 2004 09:49:48 -0700 (PDT)

> rss:item owl:sameClassAs atom:entry.

Yes and no. It allows clients to "learn" how to
process different extensions but it doesn't change the
fact that producers would be using different
extensions with the same semantics. 

Technologies like OWL and XSLT are used after the fact
to rationalize the semantically identical but
syntactically different extensions in the wild. 
 
> in RSS 1.0, both through its extension mechanism.

This does not jibe with my experiences in practice.
Can you point out how RSS 1.0 prevents duplicative
extensions in an environment that allows decentralized
extensions? Before responding, reread my comments
about OWL above. 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 21 Oct 2004 09:51:51 -0700 (PDT)

> PS. dc:author??

http://www.google.com/search?q=dc%3Aauthor+RSS

=====

---

From: Danny Ayers <[email-masked]>
Date: Thu, 21 Oct 2004 19:51:13 +0200

> extensions with the same semantics.

Ok (though I'd hesitate to use the word "learn" for something so mechanical).

> syntactically different extensions in the wild.

Yep, ok. But I'd suggest this is generally a good thing on the Web,
because it allows independent, decentralized development to take place
while maintaining a consistent global whole.

> extensions? Before responding, reread my comments

I didn't say it prevents duplication, just that it minimises it. But
ok, perhaps even that was too strong, maybe it would have been better
to say it minimises the possible variation, making duplication easier
to manage.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Thu, 21 Oct 2004 19:55:38 +0200

> http://www.google.com/search?q=dc%3Aauthor+RSS

Hmm, namespace squatting is a different issue really, I don't think
there's much we can do about that.

-- 

http://dannyayers.com

---

From: Greg Stein <[email-masked]>
Date: Fri, 22 Oct 2004 13:41:58 -0700

On Thu, Oct 21, 2004 at 07:51:13PM +0200, Danny Ayers wrote:
>...

I'm not even sure why there is a discussion. There is no way that we can
or would want to centrally-manage extensions. And I can't imagine that
people who want to provide customization would want to go through the
hoops.

In my case, if we find something that makes sense for Blogger to put into
the feed, then we'll just do that. And we'll document that extension so
that people can consume it and/or follow the same pattern with their
feeds.

A registry of extensions that people have made would be just fine, but
central management would be poor...

Cheers,
-g

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 22 Oct 2004 14:51:45 -0700

>central management would be poor...

Any registry on the Internet *has* to be managed; otherwise it will 
get filled with garbage, particularly spam from people who want to 
raise their ranking in Google^Wvarious search engines. There has to 
be some human-controlled gating function, even if it is very very low.

If there is to be one registry (as compared to many "here are the 
extensions I've seen and what I think I have heard they mean" pages), 
it has to be findable by developers.

Another option is to mandate that the namespace URIs point to 
descriptions of the extensions. That might work, but probably not 
very well, and probably not for very long.

FWIW, I'm *not* saying that, if we pick a single registry, we need to 
use IANA. If we don't, we are probably going to end up inventing 
something with IANA-like rules and less visibility and assurance of 
longevity and openness. There could be good reasons for doing that, 
but I don't see any yet.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Greg Stein <[email-masked]>
Date: Fri, 22 Oct 2004 18:01:23 -0700

> Any registry on the Internet *has* to be managed; otherwise it will

Sorry... I wasn't clear. I meant "managed" as in, "you must do X and Y to
appear in this registry and (thus) be a legal extension." i.e. some kind
of gating function to how people can extend.

I'm a strong proponent of letting people use their creativity to extend
things *without* a central authority overseeing how a standard is
extended. I would not like to see a damper on that.

[ and I might note that Atom started *because* we wanted to avoid a
  centrally-managed right to extend ]

> be some human-controlled gating function, even if it is very very low.

Agreed.

> it has to be findable by developers.

Sure. Today's search engines do very well from this standpoint. It is very
easy to find the "locus" of development efforts around any standard,
project, or other kind of specification. From there, it is hopefully very
easy to link to the central registry which describes/links to specs on how
people have extended.

> very well, and probably not for very long.

I would suggest that the namespaces remain just that: URIs. I don't think
they should be URLs, and thus, not resolvable to any meaningful info. It
is rather constraining to state that a namespace URI must be a locator.

Cheers,
-g

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 22 Oct 2004 21:43:40 -0400

> is rather constraining to state that a namespace URI must be a locator.

Which is why PURL[1] is such a great service. So good in fact that
we use in in Atom today:

    xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-03

Unfortunately it appears that our space on purl.org has fallen
into disrepair, since that URI comes up as a 404.

If we end up using URIs the use of PURL is something that
should go into the "best practices" document, along with
keeping them current ;)

[1] http://purl.org/

    -joe

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 22 Oct 2004 19:33:52 -0700

>of gating function to how people can extend.

And I still contend that you need an X and a Y and a Z, even if it is 
a very low bar. It can be as low as X="fill out an online form 
properly", and Y="have it be readable to at least one human on the 
registry team", and Z="make it an extension actually relevant to 
Atom".

Without Y, you won't be able to tell whether the thing in the unknown 
language is spam or is a request for a copy of the Atom spec or some 
such thing.

Without Z, you will be a magnet for folks who have a less firm grip 
on reality than you would want in the person sitting next to you on 
the bus. Seriously.

>extended. I would not like to see a damper on that.

Agree. But you still have to put some restrictions on the registry. 
And you will certainly hear from some of the folks who fail the Z 
test what a bunch of <expletive> <rant> <orafice> you are.

>   centrally-managed right to extend ]

With essentially any IETF protocol, one *always* has the right to 
extent. The registry is so that the extensions can be interoperable.

>project, or other kind of specification.

You maybe overestimate the value of your company's service. :-) You 
certainly overestimate the ability of typical developers ten years 
after a standard is made to understand search engine result. But it 
can be done.

>  From there, it is hopefully very

If they feel like it. Remember, many industries often have two or 
more competing trade associations; Atom could easily have this 
"feature".

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Oct 2004 22:49:00 -0400

Paul Hoffman / IMC wrote:

> And I still contend that you need an X and a Y and a Z, even if it is a 
> very low bar. It can be as low as X="fill out an online form properly", 
> and Y="have it be readable to at least one human on the registry team", 
> and Z="make it an extension actually relevant to Atom".
> 

I think Greg is against disallowing private extension. I don't think 
Paul's ideas here disallow them.

A registry for "approved extensions" seems like a good idea, but 
"approved extensions" don't make a lot of sense if they haven't been 
tried outside of someone's LAN before being approved.

I think the the concept being proposed is

"Register extensions with _____ to ensure interoperability and 
communication."

Makes sense to me.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sat, 23 Oct 2004 14:12:19 +0200

>extended. I would not like to see a damper on that.

Paul:

> "Register extensions with _____ to ensure interoperability and

It /almost/ makes sense to me. 

The notion of extension approval by committee does strike me as a
potential damper on innovation. The test of approval /should/ be
whether or not people find them useful and deploy them, but that leads
to a chicken & egg situation.

Ok, some limited editorial-style control over a registry may be needed
in practice, but the main control should be technical, i.e.
spec-conformance. The best way to implement that in a fair way would
be to produce a checklist of characteristics. Among those requirements
could be measures of age and deployment. Any extension may fulfil the
requirement on the checklist, all extensions listed in the registry
MUST fulfil those requirements.

You may be interested in a little research I did on what is the
nearest thing to a registry of RSS 2.0 extensions last year (skip the
crit of Tim!) :

http://dannyayers.com/archives/2003/08/12/bray-and-namespaces/

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 23 Oct 2004 08:56:56 -0700

>Paul's ideas here disallow them.

Completely correct. A registry helps interoperability, but in no way 
prevents anyone from emitting or accepting any extension.

A very obvious example is a human-language-specific extension for a 
language that is not spoken by the registry. For those of you who 
have curled up with the Unicode standard, this is not that 
far-fetched of an example. Some written languages have what most of 
us would consider "weird" display issues. Someone might create an 
extension for display of one part of an Atom entry if it is that 
language. They could care less if anyone else understood the 
language, so they write up the description of it in their own 
language. They can't register that because the registrar can't read 
it, but it is still a 100% valid Atom extension.

There are plenty of other scenarios where there are extensions that 
would not be registered.

>tried outside of someone's LAN before being approved.

Disagree. A reasonable registry could simply be a repository of the 
extension-writer's descriptions with no testing at all. It just says 
"if you see this namespace tag, I meant this". This policy has the 
positive side-effect of pissing off fewer people because more people 
can get their extensions registered.

At 2:12 PM +0200 10/23/04, Danny Ayers wrote:
>potential damper on innovation.

Fully agree.

>  The test of approval /should/ be

Nope, not even that far. If the test is limited to "is it legible and 
on-topic", that is sufficient.

There will be (approximately) two types of developers:

- Ones who want to read the whole registry when they start, looking 
for extensions they should handle

- Ones who watch real-world streams looking for which extensions 
exist in the wild

The first group might be disappointed to see a huge registry, but no 
one is forcing them to read everything. As long as the registry is 
skimmable, these folks should be OK. For the second group, as long as 
the registry contains everything they see in real-world streams, 
they're happy.

--Paul Hoffman, Director

---

From: Martin Duerst <[email-masked]>
Date: Mon, 25 Oct 2004 10:37:06 +0900

>A very obvious example is a human-language-specific extension for a 
language that is not spoken by the registry. For those of you who have 
curled up with the Unicode standard, this is not that far-fetched of an 
example. Some written languages have what most of us would consider "weird" 
display issues. Someone might create an extension for display of one part 
of an Atom entry if it is that language. They could care less if anyone 
else understood the language, so they write up the description of it in 
their own language. They can't register that because the registrar can't 
read it, but it is still a 100% valid Atom extension.

There are definitely some such issues. But in general, many of them
are already, and all of them they should be, covered by (X)HTML and
CSS. If you know about something that's not covered there, please
tell us, and let's fix it where the fix will have the widest possible
outreach.

Also, please note that in many cases, it's not a single language that
has the same (or very simillar) problems, so defining such extensions
by language may not be the best thing to do.

Regards,     Martin.