Hello all,
I had the action item to suggest a scheme for some sort of extensible
identifier. The issue came up with 1) chart types, and 2) form controls.
In each case, there is a number of elements which will be implemented
universally, and thus must be known universally. Also, we want to allow
for extensibility, meaning that everyone could define their own,
additional elements. And finally, if such an extension should turn out
to be useful, it should be possible that the element gets promoted to be
a standard element, or at least that an extension element can be used by
multiple applications. And the whole thing without name conflicts
between different extensions, of course.
Basically, this calls for some kind of namespaced token. I've seen two
ways how this is handled:
1) namespaced attribute values
The idea is to use namespace prefixes in attribute values. This is used
e.g. in XSD for datatypes.
Example: If the chart namespace has been declared as
xmlns:chart=".../chart", then "chart:bar" or "chart:pie" would declare a
bar chart of pie chart from the chart namespace. If a default namespace
would have been used for the same namespace, i.e. xmlns=".../chart",
then "bar" and "pie" would refer to the same to chart types. To add your
own, you can declare xmlns:my=".../mine", and then use "mine:superchart"
to declare a your new 'superchart' chart type.
2) token + URL
The idea is to have a name attribute, plus a URL attribute which is
inherited from enclosing elements. This is used e.g. in Relax-NG for
datatypes.
Example: A chart type would be declared by two attributes, a name
attribute and a chart-url attribute. The chart-url attribute is
inherited, so e.g. a chart-url attribute at the document root would
apply to all chart name attributes (unless it's overridden somewhere). A
typical document might then have a chart-url=".../chart" attribute at
the root element, and then use name values of "bar" and "pie" to declare
standard bar and pie charts. To use an own chart type, one uses the
attributes name="superchart" and chart-url=".../mine" on the chart whose
type one wants to declare.
3) full URLs
The idea is to always refer to a chart type by a full URL. To declare a
bar chart, one would use a name attribute "http://..../chart/bar".
4) pseudo-namespaced tokens
The idea is to use namespace syntax, but rely on fixed prefixes. The
standardized types would be the only ones without a colon in their name,
so at least name-clases between standard types and extensions can be
prevented. Well, this isn't used anywhere, which probably means it's a
bad idea.
Example: Name attributes "bar" and "pie" declare standardized bar and
pie charts. An attribute "my:superchart" would delcare my own, new chart
type. The prefix "my:" was chosen arbitrarily, and if someone else
choses the same prefix for their extensions, there might be name-clashes.
I tend to think of 1) as the most elegant, as it solves the problem, and
best fits into the XML world. The problem is, it's simply hard to
implement. On the spot, I couldn't think of XSLT code which can reliably
determine whether two attribute refer to the same chart type, or indeed
whether a given name refers to some predetermined chart type. But then,
my XSLT knowledge isn't that good...
I find 2) a bit klunky, but it does solve the problem. The main thing
bothering me with this one is that it manually emulates the namespace
mechanism. It is quite possible to determine which type exactly a chart
referrs two, or whether two are identical. The pro side is: If it's good
enough for Relax, it's likely good enough for us. :-)
3) also works, but seems rather ugly.
Well, 4) is a cheat, actually. It can't reliably prevent name clashes.
But then, it's the least overhead of all the methods, and would likely
be sufficient as I wouldn't expect too many people to come up with new
chart ideas. And for, say, a dozen prefixes this should be sufficiently
unambigous. E.g., Both KDE/KChart and OOo would have some rather obvious
prefix to use for their own extensions. A name-clash even without
coordination would be rather unlikely... :-)
I haven't really made up my mind on what I'd prefer. My gut feeling is
to go with 3), because it seems to have the least overhead of those
methods that actually work.
Could anyone come up with XSLT to compare two namespaced attributes, as
suggested in 1) ?
Sincerely,
Daniel