[sc34wg3] [topicmapmail] PSI issue

[G. Ken Holman]

At 2009-07-23 10:39 -0400, Patrick Durusau wrote:
>Because there are conflicts of names across namespaces.
>
>  From ODF: <meta:editing-cycles> vs. <text:editing-cycles>.
>
>Thus your suggestion becomes:
>
>http://psi.somewhere.com/odf/1.0/meta/editing-cycles
>
>http://psi.somewhere.com/odf/1.0/text/editing-cycles
>
>But by leaving out element/attribute, I lose the ability to talk about
>an attribute that may have the same value space for multiple elements.
>Yes? At least for use with one PSI.

True, but I tried to address that with a comment on 
implementation-level approaches:

At 2009-07-23 09:07 -0400, I wrote:
>Using various server-side mechanisms (rewrite, symbolic links, etc.)
>you can reduce the number of server artefacts, but the end result
>would be transparent to the user and the scheme would be, I think,
>obvious to someone who sees it without having any coaching.  After
>seeing a couple of examples, they would know what to do for any
>attribute they had.

Such schemes would allow you to have multiple web pages for the same 
named attribute, one under each element, but they would, say, 
symbolically link to the one page in the directories that documents it.

Would a user ever think about an attribute without thinking of its element?

Every "shared" attribute would be found under every element that 
shares it, so it doesn't matter which one the user uses to see the 
common documentation.  And they don't have to worry about guessing 
which element is correct (they may not even know it is a common attribute).

At 2009-07-23 10:39 -0400, Patrick Durusau wrote:
>That is for every case of an attribute I have to create the longer
>listing. Doable and I did something similar in the current ODF draft but
>duplicating the definition seems untidy at best and does tend to lose
>the information that the same value space applies across multiple elements.

The tidiness is addressed by back-end schemes, and the documentation 
for an attribute can reveal all the elements to which it applies.  It 
has to be simple so that the user doesn't have to think about how the 
scheme works ... the user won't know which attributes are shared and 
which are not ... it is up to us to bear the burden of complexity 
behind the scenes.

>Having said all that, it may be preferable to be too specific and rely
>upon a topic map engine and/or user interface to present the necessary
>information in a user friendly way. I am hopeful that PSIs are generally
>going to be presented to users as pick lists of names, etc. where the
>actual mechanics aren't really visible. Not unlike picking a font for a
>text. All sorts of things have to go right for that to happen but for
>the most part I am blissfully unaware of them. The use of PSIs should be
>the same.

Agreed.  But consistency and expectation will be important fallback 
mechanisms to rely on should there be no user interface.

>And I may be mistaken but I have the definite impression that I have
>encountered reuse of an element or attribute name, which would required
>the use of element/attribute in the path to disambiguate it.

But even if the same name is used for both an attribute and an 
element, if you categorically always put attributes "under" elements 
in the PSI path structure, there is no ambiguity.  There are no 
"top-level" attributes in the PSI scheme.

I hope this helps.

. . . . . . . . . . Ken

--
XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/t/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman at CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/t/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal