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

[Piotr Bański]

Well, yes, James, you've repeated the essence of a part of my message
that you do not quote below ;-)

Yep, it's used as notation, sometimes probably abused as notation (as is
the case with 'true' XPointer). The functionality is needed, the
question is whether parsing TEI XPointer notation by hand is as
effective as parsing parts of it nicely distributed among specialized
attributes (in other words, whether you really want to parse attribute
content when you can just parse XML). I don't know. One thing I don't
know is whether it would be realistic to try to replace the TEI XPointer
notation with a bunch of attributes. Never tried that, except for simple
cases such as @from and @to, which, I'd say, has a certain simplistic
charm to it.

The existence of a generally-deployable tool that would parse this
notation natively would certainly enhance its value and broaden its user
base.

  P.

On 02/11/11 19:15, James Cummings wrote:
> 
> I don't buy that XPointer is not being implemented. You guys are 
> thinking of standardised general-purpose implementations, but I 
> suspect that people have implemented bespoke single-use aspects 
> of it for individual projects.  So what I mean is that they've 
> used the documented TEI XPointer syntax to record information in 
> a standard way, and then processed it themselves in whatever 
> processing stream using the very limited use-cases they have. 
> Just because there isn't a wonderful all singing all dancing 
> implementation of the whole thing out there doesn't mean that 
> people aren't using the the notation to record the information 
> and doesn't mean we should just get rid of it. (I mean we only 
> added it in P5...) This means that hopefully their information 
> will make sense in the future (regardless of whether a useful 
> implementation exists).
> 
> I used string-range() once and processed it just natively in XSLT 
> (which really isn't that hard to do with substring() for the use 
> I had.
> 
> That said, if there was an XSLT2 library or a libxml 
> implementation of this, I would certainly use it.
> 
> On 02/11/11 18:00, Piotr Bański wrote:
>> 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.
>>
> 
> 


-------------- 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/14aa4b4a/attachment.bin