[sc34wg3] [topicmapmail] PSI issue

Fri Jul 24 16:15:38 EDT 2009

Ken,

Apologies for the delayed response!

And yes, I read too quickly in my first reply.

G. Ken Holman wrote:
> 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).
>
>   
I think you make a good argument for the structure you suggest for PSIs 
but to some degree I think your interpretation reflects a different 
understanding of the subject I am trying to capture.

To me, which is probably a highly individualized view, attributes 
certainly exist separate from any particular element. It is as if I have 
a store of attribute from which to select when deciding on what 
attributes should appear on an element.

However, I think your point that most users will always think of 
attributes in regard to particular elements is a good one. After all, I 
want to create a resource that will be used by users and not one that 
has the "true" view of markup languages (which is invariably the author's).

> 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.
>
>   
Well, but for some advanced modeling purposes I will need to represented 
the shared nature or perhaps co-existence of certain attributes on a 
single element but that is probably too heavy duty for a simple PSI.  
There are other topic map mechanisms to do the heavy lifting.
>> 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.
>
>   
+1!
>> 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.
>
>   
True. And that regularity could help with interfaces that want to 
present pick lists of elements or attributes to users.

Thanks!

Hope you are looking forward to a great weekend!

Patrick
> 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
>
> _______________________________________________
> topicmapmail mailing list
> topicmapmail at infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>
>   

-- 
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)