#239 Allow <uri> within <address>, <person>, <org>, etc.

[Colin Shapiro]

The element <address> contains several elements for marking up the various components of a person/organization's contact information. We have <city>, <street>, <phone>, <email>, etc. - all bits of information about how to contact a person or organization (or whatever the context may be).

However, it seems to me that something is missing: an element for marking up a website URL. Say I am writing an <address> for a company, for example; I might want to include the company's postal address, phone/fax numbers, email address, and website URL. A web URL is, like the other components, sometimes a critical piece of information about how to contact someone.

Initially I had thought about adding something to <address> such as <website>, but it was suggested to me that simply allowing <uri> within <address> might be a better solution, as it would not require the creation of a new element just for this purpose.

Thanks,
Colin

[Michael(tm) Smith]

Logged In: YES
user_id=118135
Originator: NO

I just want to chime in to say I think it would be appropriate to provide a way to associate a URI directly with a person, author, editor, othercredit, and org as well -- just as you can already directly associate an email instance with such. So I think this change should amount to allowing uri in those content models wherever email is currently allowed.

I don't think adding any new elements such as website is appropriate for this case. I think the uri should simply be a uri, with no assumption that it need actually be a http: URL for a Web page nor that it need to be referencable at all. It can simply be whatever unique identifier might be associated with the person, org, etc., that contains it. Yeah, currently it's most often and most usefully going to be a URL for a website, but in the future ... who knows.

To preempt the argument that having email in there as a means to provide a unique ID for a person is good enough, well, no it ain't. And it's especially not good enough for the case of an org. And to preempt likely objections about this change adding unnecessary complexity or whatever, well, I hope the philosophy of the TC still remains to be descriptive as much as possible rather than being prescriptive. And since the person and address models are meant to reflect real-world instances of "contact info" content, not allowing appropriate markup for URIs in a content model for contact info seems like a deficiency that ought to be corrected.

[Norman Walsh]

Logged In: YES
user_id=81663
Originator: NO

Proposal: Allow uri to occur everwhere that email occurs.

I think that's a consistent and sensible position. Many systems
represent email addresses as URIs anyway.

Specifically, this means adding uri to the content model of six
elements:

address
author
editor
org
othercredit
person

I think we should also add the following values to the list of suggested
type attribute values on URI:

homepage
weblog
webpage

[Norman Walsh]

Logged In: YES
user_id=81663
Originator: NO

Fixed.