[tei-council] Budget and Cost Saving for next year

Wed Nov 2 15:59:16 EDT 2011

This is the kind of strategic discussions we need to have in Paris. I for one would prefer the council to identify a couple of priorities where the TEI could put it budget rather than keeping an open SIG call, where we have only limited steering possibilities. How does the council feel with this in principle? Following our discussion, James could include this in his budget proposal for next year.
Laurent

Le 2 nov. 2011 à 19:00, Piotr Bański a écrit :

> XPointer assumes a different data model than XPath (obviously), and is
> meant to complement XPath in, I would say, an elegant way. It has been
> rather badly exemplified in the recommendations, and badly marketed, I'd
> say, and many people now just use workarounds. The more so that it is
> not clear to me at this point how seamlessly XPointer would incorporate
> the new, post-1.0, XPath data model.
> 
> About wanting "it" -- we text encoders need the functionality offered by
> XPointer, but we do not get it from XPointer as such. So we use
> different devices, sometimes even pretending that we use XPointer (as
> the language-resource-description format PAULA does). Using those
> different devices is probably partially a function of the lack of tool
> support (a kind of self-fulfilling prophecy, this has become at some
> point), and partially a trend for using other tools (RDF would be good
> for what XPointer does, I guess, even though the result would be way way
> more verbose; but it's hype, and tools exist). We probably do not need
> all the functionality that XPointer offers (it's very robust). It's also
> somehow patent-bound, but Liam Quin told me that this is possibly not
> such a big obstacle and that the W3C would have a way of dealing with
> this if the stuff turned out to be useful and *used*.
> 
> I don't think doing this as part of xmllib2 would be expensive in terms
> of the infrastructure. I'm not sure about the fees for a good C coder,
> but I am also sure that this could be at least attempted as a student
> project and then cost much less (because the benefits of the students
> involved would not have to be purely financial).
> 
> As far as the implementation goes, I'd say the functionality would be
> best to have as part of an XML parser, where it kind of belongs. Making
> the implementation require an XSLT or XQuery engine above something as
> ultra lightweight and fast as e.g. xmllint might harm the potential user
> base, and thus help turn the effort into a failure.
> 
> Best,
> 
>  P.
> 
> On 02/11/11 18:08, Martin Holmes wrote:
>> I guess the question, then, is whether XPointer is rarely implemented 
>> because it's hard (difficult to imagine, since it's not that distant 
>> from XPath), or because nobody wants it. If it's the latter, then we 
>> give the lie to it -- we want it, and if it's not that hard, it might 
>> not be that expensive either.
>> 
>> If we were to fund it, what kind of implementations would we want to 
>> provide? Java, C, XQuery, XSLT? I'm inclined to think that XQuery/XSLT 
>> implementations (which might share a lot of code, actually) would be 
>> easier to deploy for TEI users, who are already doing XQuery and XSLT 
>> processing of their documents. We could provide modules with examples of 
>> how to use them. C or Java implementations would be harder to integrate 
>> into existing projects.
>> 
>> Cheers,
>> Martin
>> 
>> On 11-11-02 09:46 AM, Piotr Bański wrote:
>>> Thanks, Martin, these are interesting finds. I only looked at the last
>>> link, because it offered easy access to its release history:
>>> 
>>> "Support for XPointer xpointer() schema (XPath subset only)"
>>> 
>>> That's the usual trick, unfortunately. Claim the big thing, add the
>>> small print. I'm not saying the others do the same, I will save the
>>> links for research, but I'm just pointing out that the above is the
>>> common way of (not) implementing XPointer. The TEI schemes are in a way
>>> a further step over the xpointer() scheme -- although theoretically
>>> parallel, they may/should piggyback on its internal machinery.
>>> 
>>>   P.
>>> 
>>> 
>>> On 02/11/11 17:25, Martin Holmes wrote:
>>>> I'm rather unwilling to contemplate the loss of xpointer. I found this
>>>> suggestion that it's possible to implement xpointer handling in XSLT:
>>>> 
>>>> <http://sourceforge.net/tracker/?func=detail&aid=2878239&group_id=29872&atid=776728>
>>>> 
>>>> However, the library has disappeared from the location mentioned. The
>>>> Wikipedia page links to two implementations, one Java:
>>>> 
>>>> <http://sourceforge.net/projects/cweb/>
>>>> 
>>>> and a .NET implementation:
>>>> 
>>>> <http://mvp-xml.sourceforge.net/xinclude/>
>>>> 
>>>> Cheers,
>>>> Martin
>>>> 
>>>> On 11-11-02 08:46 AM, Sebastian Rahtz wrote:
>>>>> 
>>>>> On 2 Nov 2011, at 15:40, Piotr Bański wrote:
>>>>> 
>>>>>> How exhilaratingly cruel... Announcing their potential deprecation could
>>>>>> be a way to poll the community for how much they are needed.
>>>>>> 
>>>>> yes, that would be a good action.
>>>>> 
>>>>>> The functionality behind them *is* needed, and would have to be recast
>>>>>> as individual attributes (@from, @to, ... many, I'm afraid, and in need
>>>>>> of discussion and standardization).
>>>>> 
>>>>> so if they  are needed, but don't work anywhere, how do people manage
>>>>> today? I am tempted to say that if you have survived 10 years without
>>>>> an implementation, spending money on it now may be a luxury?
>>>>> 
>>>>> I think it could actually be better to recast the stuff in pure TEI, actually,
>>>>> to avoid the impression that some software somewhere is going to implement it.
>>>>> --
>>>>> Stormageddon Rahtz
>>>>> Head of Information and Support Group
>>>>> Oxford University Computing Services
>>>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>>> 
>>>>> Sólo le pido a Dios
>>>>> que el futuro no me sea indiferente
>>>>> 
>>>>> _______________________________________________
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>> 
>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived

Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr