Lobbying for features - Revision history

Piotr Banski: /* List of projects and places where lobbying is needed */ + the SVN vote

2010-03-06T14:13:08Z

‎List of projects and places where lobbying is needed: + the SVN vote

Piotr Banski: small changes, still not done

2010-03-05T17:34:08Z

small changes, still not done

Piotr Banski: /* List of projects and places where lobbying is needed */ + Brett Zamir's campaign

2010-01-11T12:28:13Z

‎List of projects and places where lobbying is needed: + Brett Zamir's campaign

Piotr Banski: Community efforts moved to Lobbying for features: better title, I need this broad topic for something else

2009-11-13T01:34:52Z

Community efforts moved to Lobbying for features: better title, I need this broad topic for something else

Piotr Banski: small changes only, relocated the XPointer stuff

2009-11-03T02:30:29Z

small changes only, relocated the XPointer stuff

Show changes

Piotr Banski: I thought this would be a quick thing... still unfinished

2009-11-02T03:37:27Z

I thought this would be a quick thing... still unfinished

Piotr Banski: some more, but not there yet

2009-11-01T01:46:55Z

some more, but not there yet

Piotr Banski: /* Temporary Addendum: XPointer issues */

2009-10-31T05:16:57Z

‎Temporary Addendum: XPointer issues

Piotr Banski: added more, but it's still not finished

2009-10-31T03:35:41Z

added more, but it's still not finished

Show changes

Piotr Banski: unfinished

2009-10-30T15:28:40Z

unfinished

New page

[[Category:Community]]

We are a large and active community, a well-mixed blend of mostly Digital Humanities and (generally speaking) Computer Science speci-alists (needed to spoil the preceding word b/c of the spam filter...), with ties both to academia and software industry, and as such, we are potentially quite a force, a pressure group, if only our needs as TEI-ers can be identified and our efforts towards reaching them coordinated. And the power is not only in the numbers, but also, fundamentally, in the achievements of the TEI: from the widespread use of the standard in digitalizing manuscripts and literary works, through corpus/dictionary encoding, to the TEI's strong connection to Web/XML standards, such as [http://www.w3.org/TR/xlink/ XLink] or ISO 24610-1:2006 ([http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FS.html feature structure encoding]).

== Complain all you want, but then ACT ==

From time to time, we complain on the [[TEI-L]] about the insufficient software support for various devices suggested in the Guidelines (which mostly means XML manipulation or visualization). Complaining in a closed group is rarely successful, however, the outcome being usually of two kinds: either disappointment followed by surrender, or investment of one's own time and effort, possibly duplicating the work of others. The third way, however, is for the closed group to channel its pressure towards external, specialized groups, e.g. software developers or standards bodies.

Why should these external groups care about the needs of TEI-ers? As usual, mostly because they can benefit from satisfying these needs, but they need to learn about this opportunity first. Here's a list of the relevant factors:
* if there is an articulated need for feature X in our community, many of us are going to use it
* because we are a strong community, the number of users of feature X is potentially large
* software developers and standards need users to survive: users test the development versions, create feedback, suggest ideas, and '''spread the word'''
* if, therefore, the particular software package supports the features we need, a lot of mouths are going to praise it and make others use it
* and because of the above-mentioned past achievements of the TEI, it is quite possible that the currently undersupported features (think e.g. of advanced XPointer), will turn out to be indispensable in the near future, if their usefulness can be demonstrated not only in theory, but also in actual use.

== Act how? ==

How can our community exert influence on outside groups? Several ways come to mind, and the list below won't certainly be exhaustive, feel welcome to add to it.

Firstly, the perhaps most trivial way to get things done is to talk about them to people who can help. Whether we are academics, librarians or software architects -- all of us have contacts or ways of getting in contact with people in charge of software packages or participants in standards organizations (and the TEI has had a few, still does). Let's not underestimate the power of a friendly conversation over lunch or during a conference coffee break ;-)

Secondly, sometimes we happen to have a brilliant student who nevertheless needs a suggestion for his or her diploma work. If they happen to be CS students, why not have them work on an extra module to (or a modification of) an open-source package that will support the functionality the TEI needs. A job like that may actually be much more satisfying for the student than building some obscure program/package merely in order to demonstrate that they can.

Finally, and this is where I want to stop for today, there is something all of us can do as users of various kinds of software: exert pressure on the developers by indicating to them how desperately a given feature or bug-fix is needed. Let's call this feature-lobbying, because I need a title for the next subsection.

=== Feature-lobbying ===

Most projects have components designed for gathering user feedback. At this point, many readers are going to think of tedious writing of bug reports or feature requests, and they will partially be right -- after all, if you want something done, then at least make sure to signal it to the developers in such a way as to make the report easy to find and the work on it easy to track and test. However, there is also a related activity that costs much less effort, and is more in line with the tile of the section: you can vote.

The immediate impulse for writing up this article came from two sources: Michael Sperberg-McQueen's blog entry and the recent thread on TEI-L on "certainty, @match, and XPaths redux", with a subtopic on XPointer that reminded me of my own earlier feature-lobbying efforts in this area.

==== Firefox (rendering) ====
In his recent blog entry, "Firefox and namespace nodes: an open plea", Michael Sperberg-McQueen asks readers for help in feature-lobbying, by voting on [https://bugzilla.mozilla.org/show_bug.cgi?id=94270 bug94270] in [https://bugzilla.mozilla.org/ mozilla.org's Bugzilla] -- a well-known bug-tracking system. I now recall how, after Firefox 3 got released, I would bring an installation package of Firefox 2 to several conferences and either make the organizers install it or complain if they refused, because the XML links in the demo version of a certain TEI-encoded dictionary I worked well in FF 2.x only. Now I think I should have acted back then, at least by reporting this or finding a suitable report and voting on it. Silly me.

==== libxml2 ====
This is the only XML suite that has reasonably good support for XPointer's xpointer() schema. In fact, the support is rather bad... but at least it is there and can be fixed and extended if the need for it can be demonstrated.

'''I have to be running, so for now, let me merely paste a fragment of my recent e-mail, and finish the article later:'''

<pre>
Hello Laurent,

Laurent Romary writes:
> > Thanks a lot. Do you have an available implementation for string-range
> > somewhere?

Nope. I searched for freely-available free-standing XPointer-aware tools
and found out that only libxml2 (with xmllint) comes reasonably close,
but its XPointer support is incomplete and buggy. I reported some of
that on TEI-L some time ago. Since then, libxml2 has seen two bugfix
releases, but the crucial functionality is still missing.

We have a colleague, Jakub Wilk, who did some bug-hunting and submitted
a few patches to libxml2 in his free time, but I guess both his free
time and patience have run out now (which I find perfectly understandable).

In case you were interested in pursuing this further, let me give you
some links as starters:

"internal error, xpointer.c:2409" when using string-range()
https://bugzilla.gnome.org/show_bug.cgi?id=562541

Xpointer range-to function loses the end-point children
https://bugzilla.gnome.org/show_bug.cgi?id=306081

buggy range() XPointer function
https://bugzilla.gnome.org/show_bug.cgi?id=584219

buggy string-range() XPointer function
https://bugzilla.gnome.org/show_bug.cgi?id=583442

I tried to use the xpointer-schema string-range() function instead of
the TEI-defined string-range schema, but that was impossible for a
while, until this bug got fixed:

unrecognized XPointer schemes are not skipped silently
https://bugzilla.gnome.org/show_bug.cgi?id=563562

(so there is a light...)

But that would require a few complications in the markup, to provide a
cascade of XPointer schemas, with the W3C schema as fallback until the
TEI-defined schemas are supported by some tool.

Obviously, xmllint would not reach inside @corresp attributes in Adam's
example below -- some preprocessing is needed for them, and my guess is
that when the NCP actually needs string-range() or its kin to function,
the way out will be via dedicated Java-based XML-processing, similar to
what the ANC does when merging its annotations.

And having written all of the above, I realised that I could give you a
much shorter answer. Your question about an available implementation for
string-range may actually be restated more generally: "do you know of
any tool that supports any of the TEI-defined XPointer schemas?". To
that, my answer is: sadly, I know of NO such tool. xmllint is (say) half
way towards supporting the W3C-defined xpointer() scheme. Implementation
of the TEI specs would have to be a next step.

Best,

Piotr

> >
> > Le 21 sept. 09 à 19:52, Adam Przepiorkowski a écrit :
> >
>> >> Dear Laurent,
>> >>
>>> >>> I am trying to get an overview of what syntax projects are currently
>>> >>> using to refer to point in a textual or audio source. Could those of
>>> >>> you for which it is relevant give me an idea of the syntax you use
>>> >>> (e.g. string-range()), which normative reference you had in mind when
>>> >>> you did so, and maybe a tiny example of implementation (one two line
>>> >>> of XML context).
>> >>
>> >> In the National Corpus of Polish, we are planning to use string-range
>> >> in the following way:
>> >>
>> >> <p corresp="text.xml#txt_1-div" xml:id="segm_1-p">
>> >> <s xml:id="segm_1.20-s">
>> >> 
>> >> <seg corresp="text_structure.xml#string-range(txt_1.1-ab,0,6)"
>> >> xml:id="segm_1.1-seg"/>
>> >> 
>> >> <seg corresp="text_structure.xml#string-range(txt_1.1-ab,7,8)"
>> >> xml:id="segm_1.2-seg"/>
>> >> 
>> >> <seg corresp="text_structure.xml#string-range(txt_1.1-ab,16,1)"
>> >> xml:id="segm_1.3-seg"/>
>> >> ...
>> >> </s>
>> >> ...
>> >> </p>
>> >>
>> >> We are trying to follow TEI (hence the @corresp attribute).
>> >>
>> >> Best,
>> >>
>> >> Adam

</pre>

@@ Line 59: / Line 59: @@
 * Brett Zamir's [http://pledgie.com/campaigns/7732 campaign for external entities].
 * the article on [[XPointer]] contains an excerpt from the list of bugs in xmllint that need your votes to die
-* another issue concerns xmllint's treatment of the <tt>xml:lang</tt> attribute; see [https://bugzilla.gnome.org/show_bug.cgi?id=606592 Stuart Yeats' bug report on this] (and do at least consider voting)
+* another issue concerns xmllint's treatment of the <tt>xml:lang</tt> attribute; see [https://bugzilla.gnome.org/show_bug.cgi?id=606592 Stuart Yeats' bug report on this] (and do at least consider voting, i.e. adding your address to the CC list)

@@ Line 1: / Line 1: @@
 [[Category:Community]]
-'''This is still very much in the making; the section on [[XPointer]] has been moved to a separate page; I should also change the title of this article at some point. Comments are welcome.''' [[User:Piotr Banski|Piotr]] 21:30, 2 November 2009 (EST)
+'''This is still very much in the making; the section on [[XPointer]] has been moved to a separate page; comments are welcome.'''<br />[[User:Piotr Banski|Piotr]] 21:30, 2 November 2009 (EST)
 Although it is a firmly established standard by now, the TEI has to constantly evolve for basically three reasons: it needs to improve, it needs to expand (think e.g. ontology markup or modern corpus formats), and it needs to keep up with the evolving technology of its medium of expression, i.e., XML. This means that, however hard we try, there will always be a risk of a clash between the needs of TEI users and the broadly understood technological limitations, such as the issue of compliance with the ever-developing basic standards (think XPath 1.0/2.0 and [[XPointer]] for addressing; recall also the move from SGML/P3 to XML/P4-P5), or the numerous tools used for authoring, processing, querying and rendering.
@@ Line 39: / Line 39: @@
 Let me illustrate this on the example of [http://www.bugzilla.org/about/ Bugzilla] -- a well-known and popular bug-tracking system. In his recent blog entry, "[http://cmsmcq.com/mib/?p=757 Firefox and namespace nodes: an open plea]", Michael Sperberg-McQueen asks his readers for help in lobbying, by voting on [https://bugzilla.mozilla.org/show_bug.cgi?id=94270 bug report number 94270] to be moved higher in the priority of Mozilla developers. You can see there both the CC list on the right and the number of votes on the left of it. (Incidentally, note also that the report is keyworded as a 'student-project', which means exactly what you think.)
+'''from this point on, sketchy notes follow, to be tidied up some day... '''
-'''ENOUGH FOR NOW :-) '''
+<!-- Voting is simple but as a "lobbying" technique, it has a disadvantage: while you let the developer know that there is a demand for some feature, you most often fail to let them know that they can benefit from supporting it, because the demand comes from a serious standard with a large user base.
 (Mention other easy ways to help -- testing with current software versions, etc.)
+-->
 Stuff worth linking to, perhaps:
@@ Line 56: / Line 52: @@
 * [http://markmail.org/message/ju4l6xt5griwczlo Henry S. Thompson's mail to xml-dev on the above]
 * http://www.w3.org/Bugs/Public/query.cgi --  W3C bugzilla
 == List of projects and places where lobbying is needed ==
@@ Line 63: / Line 57: @@
 This is to be the climax of this article: I would like to put here a list of places where members of the TEI community can go and e.g. cast their votes or help in bug triaging, etc.
-Here's something for a start: Brett Zamir's [http://pledgie.com/campaigns/7732 campaign for external entities].
+* Brett Zamir's [http://pledgie.com/campaigns/7732 campaign for external entities].
-== Temporary Addendum: XPointer issues ==
+Have a look at a story of another, successful, two-person [[Sourceforge topic categories|campaign for "TEI" as an official Sourceforge data category]].
 ----
 If for some reason you do not want to use the [[{{TALKPAGENAMEE}}|discussion page]], I welcome comments by [[Special:Emailuser/Piotr_Banski|e-mail]]. [[User:Piotr Banski|Piotr]] 23:35, 30 October 2009 (EDT)

@@ Line 61: / Line 61: @@
 == List of projects and places where lobbying is needed ==
-This is to be the climax of this article: I would like to put here a list of places where members of the TEI community can go and e.g. cast their votes or help in bug triaging, etc. More tomorrow.
+This is to be the climax of this article: I would like to put here a list of places where members of the TEI community can go and e.g. cast their votes or help in bug triaging, etc.
 == Temporary Addendum: XPointer issues ==

@@ Line 1: / Line 1: @@
 [[Category:Community]]
 We are a large and active community, a well-mixed blend of mostly Digital Humanities and (generally speaking) Computer Science professionals, with ties both to academia and software industry, and as such, we are potentially quite a force, a pressure group, if only our needs as TEI-ers can be identified and our efforts towards reaching them coordinated. And the power is not only in the numbers, but also, fundamentally, in the achievements of the TEI: from the widespread use of the standard in digitalizing manuscripts and literary works, through corpus/dictionary encoding, to the TEI's strong connection to Web/XML standards, such as [http://www.w3.org/TR/xlink/ XLink] or ISO 24610-1:2006 ([http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FS.html feature structure encoding]).
 == Complain all you want, but then ACT ==
-From time to time, we complain on the [[TEI-L]] about the insufficient software support for various devices/techniques suggested in the Guidelines (mostly, this pertains to XML manipulation or visualization). Complaining in a closed group is rarely successful, however, the outcome being usually of two kinds: either disappointment followed by surrender, or investment of one's own time and effort at the cost of the project at hand and possibly duplicating the work of others. The third way, however, is for the closed group to channel its pressure towards external, specialized groups, e.g. software developers or standards bodies.
+From time to time, we complain on the [[TEI-L]] about the insufficient software support for various devices/techniques suggested in the Guidelines (mostly, this pertains to XML manipulation or visualization). Complaining in a closed group is rarely successful, however, the outcome being usually of two kinds: either disappointment followed by surrender, or investment of one's own time and effort in eliminating the obstacle, at the cost of the project at hand and possibly duplicating the work of others. The third way, however, is for the closed group to channel its pressure towards external, specialized groups, e.g. software developers or standards bodies.
-Why should these external groups care about the needs of TEI-ers? As usual, mostly because they can benefit from satisfying these needs -- but they need to learn about this opportunity first. Here's a list of the relevant factors:
+Why should these external groups care about the needs of TEI-ers? As usual, mostly because they can benefit from satisfying these needs -- but they need to learn about this opportunity first. Here's a list of the factors that might be relevant in such cases:
 * if there is an articulated need for feature X in our community, many of us are going to use it
 * because we are a strong community, the number of users of feature X is potentially large
@@ Line 14: / Line 20: @@
 * once some of us start using X, it becomes a standard feature, recommended by the Guidelines and practice, and thus more of us may start using it (at this point, loop two bullets up)
 * and because of the above-mentioned past achievements of the TEI, it is quite possible that the currently undersupported features (think e.g. of advanced XPointer), will turn out to be indispensable in the near future, if their usefulness can be demonstrated not only in theory, but also in actual use; the one who supports it early reaps most of the harvest (think [[Saxon]], always at the front with respect to [[XSLT]] standards support).
 == Act how? ==
@@ Line 21: / Line 29: @@
 Firstly, perhaps the most trivial way to get things done is to talk about them to people who can help. Whether we are teachers/researchers, librarians or software architects -- all of us have contacts or ways of getting in contact with people in charge of software packages or participants in standards organizations (and the TEI has had a few, still does). Let's not underestimate the power of a friendly conversation over lunch or during a conference coffee break ;-)
-Secondly, sometimes we happen to have a brilliant student who nevertheless needs a suggestion for his or her diploma work. If they happen to be CS students, why not have them work on an extra module to (or a modification of) an open-source package that will support the functionality the TEI needs. A job like that may actually be much more satisfying for the student than building some obscure program/package merely in order to demonstrate that they can.
+Secondly, sometimes we happen to have a brilliant student who nevertheless needs a suggestion for his or her diploma work. If they happen to be CS students, why not have them work on an extra module to (or a modification of) an open-source package that will support the functionality the TEI needs. A job like that may actually be much more satisfying for the student than building some obscure program/package merely in order to demonstrate that they can. In fact, some software projects may designate some areas for supervised student work -- as is the case of [https://wiki.mozilla.org/Education/Projects Mozilla Education project]. Note that even the philologists among us have colleagues at Computer Science departments who may be interested in this.
 Finally, and this is what I want to focus on here, there is something all of us can do as users of various kinds of software: exert pressure on the developers by indicating to them how desperately a given feature or bug-fix is needed. Let me call this lobbying for features.
@@ Line 27: / Line 35: @@
 == Lobbying for features ==
-Most projects have components designed for gathering user feedback. At this point, many readers are going to think of tedious writing of bug reports or feature requests, and they will partially be right -- after all, if you want something done, then at least make sure to signal it to the developers in such a way as to make the report easy to find and the work on it easy to track and test. However, there is also a related activity that costs much less effort, and is more in line with the tile of the section: you can '''vote'''. Voting is simple but as a "lobbying" technique, it has a disadvantage: while you let the developer know that there is a demand for some feature, you most often fail to let them know that they can benefit from supporting it, because the demand comes from a serious standard with a large user base. But it's better than nothing, so if I can talk at least some of us into at least voting, I'll be glad.
+Most projects have components designed for gathering user feedback. At this point, many readers are going to think of tedious writing of bug reports or feature requests, and they will partially be right -- after all, if you want something done, then at least make sure to signal it to the developers in such a way as to make the report easy to find and the work on it easy to track and test. However, there is also a related activity that costs much less effort: we can indirectly indicate to the developers that the number of users affected by the given problem is high, by voting and/or adding our e-mail addresses to the CC list for the report.
 Stuff worth linking to, perhaps:
 * https://bugzilla.mozilla.org/show_bug.cgi?id=22942 "(entities) Load external DTDs (entity/entities) (local and remote) if a pref is set"
 * [http://markmail.org/message/ju4l6xt5griwczlo Henry S. Thompson's mail to xml-dev on the above]
 * http://www.w3.org/Bugs/Public/query.cgi --  W3C bugzilla
 The immediate impulse for writing up this article came from two sources: Michael Sperberg-McQueen's blog entry and the recent thread on TEI-L on "[http://listserv.brown.edu/archives/cgi-bin/wa?S2=TEI-L&q=&s=XPaths+redux&f=&a=&b= certainty, @match, and XPaths redux]", with a subtopic on XPointer that reminded me of my own earlier lobbying efforts in this area. Let me briefly go over these two example cases below, and then, in the next section, open the space where the TEI community should be able to find some suggestions on how and where exactly to act.

@@ Line 5: / Line 5: @@
 == Complain all you want, but then ACT ==
-From time to time, we complain on the [[TEI-L]] about the insufficient software support for various devices/techniques suggested in the Guidelines (mostly, this pertains to XML manipulation or visualization). Complaining in a closed group is rarely successful, however, the outcome being usually of two kinds: either disappointment followed by surrender, or investment of one's own time and effort, possibly duplicating the work of others. The third way, however, is for the closed group to channel its pressure towards external, specialized groups, e.g. software developers or standards bodies.
+From time to time, we complain on the [[TEI-L]] about the insufficient software support for various devices/techniques suggested in the Guidelines (mostly, this pertains to XML manipulation or visualization). Complaining in a closed group is rarely successful, however, the outcome being usually of two kinds: either disappointment followed by surrender, or investment of one's own time and effort at the cost of the project at hand and possibly duplicating the work of others. The third way, however, is for the closed group to channel its pressure towards external, specialized groups, e.g. software developers or standards bodies.
-Why should these external groups care about the needs of TEI-ers? As usual, mostly because they can benefit from satisfying these needs, but they need to learn about this opportunity first. Here's a list of the relevant factors:
+Why should these external groups care about the needs of TEI-ers? As usual, mostly because they can benefit from satisfying these needs -- but they need to learn about this opportunity first. Here's a list of the relevant factors:
 * if there is an articulated need for feature X in our community, many of us are going to use it
 * because we are a strong community, the number of users of feature X is potentially large
 * software developers and standards need users to survive: users test the development versions, create feedback, suggest ideas, and '''spread the word'''
 * if, therefore, the particular software package supports the features we need, a lot of mouths are going to praise it and make others use it
-* and because of the above-mentioned past achievements of the TEI, it is quite possible that the currently undersupported features (think e.g. of advanced XPointer), will turn out to be indispensable in the near future, if their usefulness can be demonstrated not only in theory, but also in actual use; the one who supports it early reaps most of the harvest (think [[Saxon]], always on the front line with respect to [[XSLT]] standards support).
+* once some of us start using X, it becomes a standard feature, recommended by the Guidelines and practice, and thus more of us may start using it (at this point, loop two bullets up)
 == Act how? ==
-How can our community exert influence on outside groups? Several ways come to mind, and the list below won't certainly be exhaustive, feel welcome to add to it.
+How can our community exert influence on outside groups? Several ways come to mind, and the list below won't certainly be exhaustive, feel welcome to [[{{TALKPAGENAMEE}}|discuss others]].
-Firstly, the perhaps most trivial way to get things done is to talk about them to people who can help. Whether we are teachers/researchers, librarians or software architects -- all of us have contacts or ways of getting in contact with people in charge of software packages or participants in standards organizations (and the TEI has had a few, still does). Let's not underestimate the power of a friendly conversation over lunch or during a conference coffee break ;-)
+Firstly, perhaps the most trivial way to get things done is to talk about them to people who can help. Whether we are teachers/researchers, librarians or software architects -- all of us have contacts or ways of getting in contact with people in charge of software packages or participants in standards organizations (and the TEI has had a few, still does). Let's not underestimate the power of a friendly conversation over lunch or during a conference coffee break ;-)
 Secondly, sometimes we happen to have a brilliant student who nevertheless needs a suggestion for his or her diploma work. If they happen to be CS students, why not have them work on an extra module to (or a modification of) an open-source package that will support the functionality the TEI needs. A job like that may actually be much more satisfying for the student than building some obscure program/package merely in order to demonstrate that they can.
-Finally, and this is what I want to focus on, there is something all of us can do as users of various kinds of software: exert pressure on the developers by indicating to them how desperately a given feature or bug-fix is needed. Let me call this lobbying for features.
+Finally, and this is what I want to focus on here, there is something all of us can do as users of various kinds of software: exert pressure on the developers by indicating to them how desperately a given feature or bug-fix is needed. Let me call this lobbying for features.
 == Lobbying for features ==
-Most projects have components designed for gathering user feedback. At this point, many readers are going to think of tedious writing of bug reports or feature requests, and they will partially be right -- after all, if you want something done, then at least make sure to signal it to the developers in such a way as to make the report easy to find and the work on it easy to track and test. However, there is also a related activity that costs much less effort, and is more in line with the tile of the section: you can '''vote'''.
+Most projects have components designed for gathering user feedback. At this point, many readers are going to think of tedious writing of bug reports or feature requests, and they will partially be right -- after all, if you want something done, then at least make sure to signal it to the developers in such a way as to make the report easy to find and the work on it easy to track and test. However, there is also a related activity that costs much less effort, and is more in line with the tile of the section: you can '''vote'''. Voting is simple but as a "lobbying" technique, it has a disadvantage: while you let the developer know that there is a demand for some feature, you most often fail to let them know that they can benefit from supporting it, because the demand comes from a serious standard with a large user base. But it's better than nothing, so if I can talk at least some of us into at least voting, I'll be glad.
-The immediate impulse for writing up this article came from two sources: Michael Sperberg-McQueen's blog entry and the recent thread on TEI-L on "certainty, @match, and XPaths redux", with a subtopic on XPointer that reminded me of my own earlier lobbying efforts in this area.
+'''not sure any more the personal stories below are worth anything; will probably move more or less directly to the final section'''
 === Firefox (rendering, client-side on-the-fly transformation) ===
-In his recent blog entry, "Firefox and namespace nodes: an open plea", Michael Sperberg-McQueen asks readers for help in feature-lobbying, by voting on [https://bugzilla.mozilla.org/show_bug.cgi?id=94270 bug94270] in [https://bugzilla.mozilla.org/ mozilla.org's Bugzilla] -- a well-known bug-tracking system. I now recall how, after Firefox 3 got released, I would bring an installation package of Firefox 2 to several conferences and either make the organizers install it or complain if they refused, because XPointer-based XML links in the demo version of a certain TEI-encoded dictionary I presented worked well in FF 2.x only. Now I think I should have acted back then, at least by reporting this in the Bugzilla or by finding a suitable report and voting on it. Silly me.
+In his recent blog entry, "[http://cmsmcq.com/mib/?p=757 Firefox and namespace nodes: an open plea]", Michael Sperberg-McQueen asks his readers for help in lobbying, by voting on [https://bugzilla.mozilla.org/show_bug.cgi?id=94270 bug94270] in [https://bugzilla.mozilla.org/ mozilla.org's Bugzilla] -- a well-known bug-tracking system. I now recall how, after Firefox 3 got released, I would bring an installation package of Firefox 2 to several conferences and either make the organizers install it or complain if they refused, because XPointer-based XML links in the demo version of a certain TEI-encoded dictionary I presented worked well in FF 2.x only. Now I think I should have acted back then, at least by reporting this in the Bugzilla or by finding a suitable report and voting on it. Silly me.
 === libxml2 (validation, XInclude, XPointer, transformation) ===
@@ Line 40: / Line 50: @@
 I have reported or commented on several XPointer/XInclude-related bugs in libxml2, but without votes, testing and comments from others, fixing them may take a while (insert link to Daniel Veillard's mail here). I have even to talk a colleague into providing a few patches, with some success (link to Jakub Wilk's report of the bug persisting).
-'''This section is messy and will remain so for at least several hours, because I need some sleep :-)'''
 Have to extract some bits from this fragment still.
@@ Line 144: / Line 156: @@
 ----
-If for some reason you do not want to use the [[Talk:Community_efforts|discussion page]], I welcome comments by [[Special:Emailuser/Piotr_Banski|e-mail]]. [[User:Piotr Banski|Piotr]] 23:35, 30 October 2009 (EDT)
+If for some reason you do not want to use the [[{{TALKPAGENAMEE}}|discussion page]], I welcome comments by [[Special:Emailuser/Piotr_Banski|e-mail]]. [[User:Piotr Banski|Piotr]] 23:35, 30 October 2009 (EDT)

← Older revision	Revision as of 01:34, 13 November 2009
(No difference)

@@ Line 103: / Line 103: @@
 Apart from element(), there is also the [http://www.w3.org/TR/xptr-xmlns/ xmlns() scheme] that does namespace binding, and finally the [http://www.w3.org/TR/xptr-xpointer/ xpointer() scheme] that does an incredible lot of useful things in a very clever way, except it's not supported in full anywhere, '''and that should change''' (see above).
-The three schemes mentioned above have been defined or, in the case of xpointer(), drafted, by the W3C. The XPointer Framework, however, allows other parties to define their own schemes and get them registered in a special corner of the W3C called the [http://www.w3.org/2005/04/xpointer-schemes/ XPointer Registry]. And this is the point where we, as the TEI community, may want to focus some of our attention. Thanks to Syd Bauman, a number of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSTEI-defined schemes] (described in the ''Linking and Alignment'' chapter of the Guidelines) have been registered with the W3C. One of them, [http://simonstl.com/ietf/draft-stlaurent-xpath-frag-01.txt xpath1()], is actually shared with other Internet communities, and implemented in Firefox (as far as I know). Among them is, e.g., the string-range() scheme.
+The three schemes mentioned above have been defined or, in the case of xpointer(), drafted, by the W3C. The XPointer Framework, however, allows other parties to define their own schemes and get them registered in a special corner of the W3C called the [http://www.w3.org/2005/04/xpointer-schemes/ XPointer Registry]. And this is the point where we, as the TEI community, may want to focus some of our attention. Thanks to Syd Bauman, a number of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSTEI-defined schemes] (described in the ''Linking and Alignment'' chapter of the Guidelines) have been registered with the W3C. One of them, [http://simonstl.com/ietf/draft-stlaurent-xpath-frag-01.txt xpath1()], is actually shared with other Internet communities, and implemented in Firefox (as far as I know). Another is the string-range() scheme, useful in stand-off applications that address into the content of elements.
 The structure of the XPointer Framework is illustrated below: