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

[Piotr Bański]

Ah,

I've had a closer look at the SF ticket too:

"The following schemes are supported by this implementation:
- XPointer element() Scheme
- XPointer xmlns() Scheme
- XPointer xmlns-local() Scheme
- XPointer xpath1() Scheme
- XPointer xpath2() Scheme"

Crucially, the omission of the xpointer() scheme kind of screams out.

I've always thought it completely unimaginative to use the same name for
the entire framework (XPointer) as for one of its schemes (xpointer()).
But at least some people can use it for a PR effect.

  P.

On 02/11/11 17:46, 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


-------------- 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/e4d1cf6c/attachment-0001.bin