OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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]