[tei-council] Use of @cRef

[Kevin Hawkins]

It seems to me that private URI schemes relates to the question of 
private URN schemes and the future of @key.  See:

http://sourceforge.net/tracker/index.php?func=detail&group_id=106328&atid=644065&aid=3437509

Do we dare ask about people's use of @key as well?

On 2/1/2012 8:24 AM, Martin Holmes wrote:
> I'm not sure whether I want to introduce the explanation of private URI
> schemes into the survey; it's really just trying to discover what people
> are currently doing with @cRef, and presumably nobody is using it that
> way; if they know about private URI schemes, they would naturally tend
> to put them into @target, I think.
>
> But the issue of private URI schemes is definitely something else we
> have to deal with. Whatever we do with @cRef, I think we should be
> encouraging people using private URI schemes to provide the same sort of
> canonical resolution pattern for any private scheme used in e.g. @target
> as they would when using @cRef in the traditional way.
> @target="foo:blort" is no less cryptic than @cRef="blort". This might
> require that we review at least the name of<cRefPattern>, turning it
> into<refPattern>,<uriSchemePattern>, or something like that.
>
> Not that I'm complying with this myself, of course. I'm guilty of using
> both @target="foo:blort" and @cRef="blort" without a<refsDecl>, and I
> should be ashamed of myself.
>
> Cheers,
> Martin
>
> On 12-02-01 02:21 AM, James Cummings wrote:
>>
>> I like the survey, but should it be explained that data.pointer
>> can take a URI of the form foo:blort etc?  i.e. that their @cRefs
>> probably can be easily represented as pointers?
>>
>> -James
>>
>>
>> On 31/01/12 16:56, Martin Holmes wrote:
>>> Hi all,
>>>
>>> The attribute @cRef (which appears on<ref>,<ptr>,<gloss>    and<term>)
>>> is currently a bit of a mess. I've started a bug for this:
>>>
>>> <http://purl.org/TEI/BUGS/3480650>
>>>
>>> Changes have to be made to @cRef -- for one thing, the attribute is
>>> separately defined for each element, with different datatypes. It has
>>> been suggested that we no longer actually need it, because its original
>>> function (storing a canonical reference from a scheme defined in a
>>> <refsDecl>    element in the TEI header) can perfectly well be handled
>>> using @target, using a private URI scheme. However, it's arguable that
>>> having an attribute whose purpose is explicitly to handle private URI
>>> schemes (as opposed to official IANA-registered schemes) might be
>>> useful. If we were to switch to recommending @target and private URI
>>> schemes, I think we'd have to encourage people to provide resolution
>>> patterns for such schemes as we currently do with @cRef.
>>>
>>> It would be helpful to get a sense of what people are currently doing
>>> with @cRef, and how changes are likely to affect existing projects. I
>>> thought about a little survey we could circulate to TEI-L -- something
>>> like this:
>>>
>>> <http://www.surveymonkey.com/s.aspx?PREVIEW_MODE=DO_NOT_USE_THIS_LINK_FOR_COLLECTION&sm=Fpob1swo7qmZTEW4PbIxL9EDe24HTX6Wad91ehsQajc%3d>
>>>
>>> What do you think about this? (Assuming you can see the survey -- I'm
>>> not sure exactly how SurveyMonkey works in this regard, never having
>>> used it before. If you can't see it, let me know and I'll copy/paste the
>>> questions into an email.)
>>>
>>> I'd like to make some decisions about @cRef at the April meeting if
>>> that's possible, so a bit of prep now seems like a good idea.
>>>
>>> Cheers,
>>> Martin
>>
>>