Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

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

v5.0
closed-fixed
Norman Walsh
DocBook (176)
5
2007-09-27
2007-07-24
Colin Shapiro
No

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

Discussion

  • 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.

     
    • summary: Allow <uri> within
      --> Allow <uri> within
      , <person>, <org>, etc.
     
  • Norman Walsh
    Norman Walsh
    2007-08-29

    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
    Norman Walsh
    2007-09-27

    • milestone: --> v5.0
     
  • Norman Walsh
    Norman Walsh
    2007-09-27

    Logged In: YES
    user_id=81663
    Originator: NO

    Fixed.

     
  • Norman Walsh
    Norman Walsh
    2007-09-27

    • status: open --> closed-fixed