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

Wed Nov 2 14:00:21 EDT 2011

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4054 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20111102/19bf08f6/attachment.bin 