[ docbook-RFEs-1759782 ] Allow <uri> within <address>, <person>, <org>, etc.

[SourceForge.net <no...@so...>]

RFEs item #1759782, was opened at 2007-07-25 01:27
Message generated for change (Comment added) made by xmldoc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=384107&aid=1759782&group_id=21935

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DocBook
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Colin Shapiro (cmshapiro)
Assigned to: Norman Walsh (nwalsh)
>Summary: Allow <uri> within <address>, <person>, <org>, etc.

Initial Comment:
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

----------------------------------------------------------------------

>Comment By: Michael(tm) Smith (xmldoc)
Date: 2007-07-26 16:21

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=384107&aid=1759782&group_id=21935