headers
Sebastian Rahtz | 1 Dec 2006 13:45
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Syd Bauman wrote:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1022701&group_id=106328&atid=644065.
>   
which has partly been acted on, in that <address> allows members
of the class model.addrPart. So one could define <email> as a member
of that class.
> Until such time as there is an <email> element or <resource> element,
> I would transform the above <xptr> into
>   
perhaps better than

   <ptr target='mailto:joe <at> blogs.edu'/>

would be

<ref  target='mailto:joe <at> blogs.edu'>joe <at> blogs.edu </ref>

Another alternative would be <addrLine type="email">joe <at> blogs.edu</addrLine>

or  (which seems honest to me)

 <address type="email">
  <addrLine>joe <at> blogs.edu</addrLine>
 </address>

(if <address> were typeable which sadly it aint)

sebastian
(Continue reading)

Permalink | Reply | 10 comments |
headers
James Cummings | 1 Dec 2006 14:51
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Sebastian Rahtz wrote:
> Another alternative would be <addrLine
> type="email">joe <at> blogs.edu</addrLine>
> 
> or  (which seems honest to me)
> 
> <address type="email">
>  <addrLine>joe <at> blogs.edu</addrLine>
> </address>
> 
> (if <address> were typeable which sadly it aint)

Since 'address' is defined as containing "a postal or other address"
whereas 'addrLine' is defined as "contains one line of a postal or other
address" noting that "Addresses may be encoded either as a sequence of lines, or
using any sequence of address component elements.", then I don't think that
markup makes sense.  Because it implies that 'joe <at> blogs.edu' is a single
physical line of an address, where really it is a different type of address as a
whole.

So really:
<address type="email">
  <email>joe <at> blogs.edu</email>
</address>

would make more sense if it existed.

I realize I'm splitting hairs and that <addrLine> is probably the best solution
for now, but just wanted to support the argument that there needs to be an
<email> in model.addrPart.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Sebastian Rahtz | 1 Dec 2006 14:52
Picon
Picon
Favicon

Re: Encoding email addresses in P5

James Cummings wrote:
>
> So really:
> <address type="email">
>   <email>joe <at> blogs.edu</email>
> </address>
>
> would make more sense if it existed.
>
>
>   
thats redundant, surely. both "type='email'" _and_ <email>.

<address type="email">
 <addrLine>joe</addrLine>
 <addrLine>blogs.edu</addrLine>
</address>

has some attraction

sebastian
Permalink | Reply | 8 comments |
headers
James Cummings | 1 Dec 2006 15:06
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Sebastian Rahtz wrote:
> James Cummings wrote:
>>
>> So really:
>> <address type="email">
>>   <email>joe <at> blogs.edu</email>
>> </address>
>>
>> would make more sense if it existed.
>>
>>
>>   
> thats redundant, surely. both "type='email'" _and_ <email>.

You're right, I should have removed the ' <at> type'.  (And it bothers me that
address isn't type'able since its definition says "postal _or other_" how are
you supposed to indicate what other kind it is?)

> <address type="email">
> <addrLine>joe</addrLine>
> <addrLine>blogs.edu</addrLine>
> </address>
> has some attraction

Only if we change the understanding of addrLine not to refer to physical lines
of an address. The username and domain name are not separate lines.  However:

<address>
<email>
<username>joe</username>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Sebastian Rahtz | 1 Dec 2006 15:10
Picon
Picon
Favicon

Re: Encoding email addresses in P5

James Cummings wrote:
> Only if we change the understanding of addrLine not to refer to physical lines
> of an address. 
you introduced the word "physical" here, not the TEI. I can
read "one line of a postal or other address" as being able
to refer to one of the two components of an email address.

as usual, we run up against the descriptive vs prescriptive thing.

in a descriptive context

 OUCS
 University of Orfxford
 s.rahtz <at> oucs.com

is reasonable regarded as 3 lines of the address. but
not in a prescriptive context where lines 1 and 2 are
an alternative to line 3

sebastian
Permalink | Reply | 6 comments |
headers
James Cummings | 1 Dec 2006 15:25
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Sebastian Rahtz wrote:

> you introduced the word "physical" here, not the TEI. I can
> read "one line of a postal or other address" as being able
> to refer to one of the two components of an email address.

The guidelines refer to the concept "as they might be printed on an envelope"...
when discussing this previously I was told that the address you cite below is
two addresses.  One is:
<address>
 <addrLine>OUCS</addrLine>
 <addrLine>University of Orfxford</addrLine>
</address>
the other is:
<email>s.rahtz <at> oucs.com</email>

> is reasonable regarded as 3 lines of the address. but
> not in a prescriptive context where lines 1 and 2 are
> an alternative to line 3

Yup. Absolutely right.  So is the solution to create a class which contains
address and email as well as allowing email inside address?

I really should keep my word and shut up.  I mean the feature request was filed
by one of the editors on 2004-09-05, I'm sure it will be resolved soon.

-James

--

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
(Continue reading)

Permalink | Reply | 5 comments |
headers
Martin Holmes | 1 Dec 2006 19:14
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Hi there,

James Cummings wrote:

> The guidelines refer to the concept "as they might be printed on an envelope"...
> when discussing this previously I was told that the address you cite below is
> two addresses.  One is:
> <address>
>  <addrLine>OUCS</addrLine>
>  <addrLine>University of Orfxford</addrLine>
> </address>
> the other is:
> <email>s.rahtz <at> oucs.com</email>
> 
>> is reasonable regarded as 3 lines of the address. but
>> not in a prescriptive context where lines 1 and 2 are
>> an alternative to line 3
> 
> Yup. Absolutely right.  So is the solution to create a class which contains
> address and email as well as allowing email inside address?
> 
> I really should keep my word and shut up.  I mean the feature request was filed
> by one of the editors on 2004-09-05, I'm sure it will be resolved soon.

I vote that you keep talking until somebody makes a decision. It's a bit 
daft that there's no standard way to encode an email address in a P5 
document. I think the simplest thing is to have an <email> tag:

<email>joe <at> bloggs.com</email>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Mueller | 1 Dec 2006 19:32
Favicon

Re: Encoding email addresses in P5

I'm with Martin Holmes on this one. You can argue endlessly where it  
should be in some hierarchy, but email is email and sui generis. So  
it's worth promoting it to a tag of its own even if it breaks some  
logic somewhere.

It reminds me a little of the Apple Finder, which shows you  
Applications, Documents, your home directory, and destop on the same  
level even though they aren't. Sometimes practicality trumps.

On Dec 1, 2006, at 12:14 PM, Martin Holmes wrote:

> Hi there,
>
> James Cummings wrote:
>
>> The guidelines refer to the concept "as they might be printed on  
>> an envelope"...
>> when discussing this previously I was told that the address you  
>> cite below is
>> two addresses.  One is:
>> <address>
>>  <addrLine>OUCS</addrLine>
>>  <addrLine>University of Orfxford</addrLine>
>> </address>
>> the other is:
>> <email>s.rahtz <at> oucs.com</email>
>>> is reasonable regarded as 3 lines of the address. but
>>> not in a prescriptive context where lines 1 and 2 are
>>> an alternative to line 3
>> Yup. Absolutely right.  So is the solution to create a class which
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sebastian Rahtz | 1 Dec 2006 21:12
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Martin Mueller wrote:
> I'm with Martin Holmes on this one. You can argue endlessly where it 
> should be in some hierarchy, but email is email and sui generis.
is it? why isn't my mobile phone number of the same gener? or my
home url? or my del.icio.us location?
t'other Martin said:
>>
>> I vote that you keep talking until somebody makes a decision. 
if only the decision-making system worked like that. as you
can tell, once something enters the Sargasso Sea of
the Sourceforge list, you can wait years for a breath of wind.
>> I'd say let <address> be postal, and <email> be different, and just 
>> put <email> into model.pPart.data  and model.publicationStmtPart. 
>> Surely this is a case where there's a clear need for a simple decision,
I'm with you there
>> and agonizing over it for another two years will result in a 
>> proliferation of different approaches which will make it impossible 
>> for us to reliably pick out email addresses from P5 document 
>> collections because they'll all be encoded differently.
but that's the TEI Way (tm)......

Sebastian
Permalink | Reply | 2 comments |
headers
Martin Holmes | 1 Dec 2006 22:35
Picon
Picon
Favicon

Re: Encoding email addresses in P5

Hi there,

Sebastian Rahtz wrote:

>>> I vote that you keep talking until somebody makes a decision. 
> if only the decision-making system worked like that. as you
> can tell, once something enters the Sargasso Sea of
> the Sourceforge list, you can wait years for a breath of wind.

This interests me. I have no idea how, when or in what manner the TEI 
decides on issues like this, and I've asked a couple of times of folks 
who should know, being involved, and they don't seem to know either. 
When something is filed on SourceForge, it should presumably end up on 
the agenda of a specific meeting for consideration, shouldn't it? If the 
only thing that causes a feature request or a bug report ever to be 
considered is that a member of the committee happens to take a personal 
interest in it, then everything that doesn't happen to have a champion 
on the committee will die and disappear.

Is there a formal procedure with timelines and regular meetings?

Cheers,
Martin

--

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes <at> uvic.ca)
Half-Baked Software, Inc.
(mholmes <at> halfbakedsoftware.com)
(Continue reading)

Permalink | Reply | 0 comments |