[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Extensible IDs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]