[sc34wg3] [topicmapmail] PSI issue

[G. Ken Holman]

At 2009-07-23 06:32 -0400, you wrote:
>I am trying to design PSIs to represent the markup constructs of both
>ISO 26300 and ISO 29500.

Interesting!  I have had a number of false starts trying to initiate 
PSI projects.

>I am considering generating PSIs along the lines of:
>
>http://psi.somewhere.com/odf/element/(elementName).html
>
>http://psi.somewhere.com/odf/attribute(attributeName).html
>
>http://psi.somewhere.com/ooxml/element/(elementName).html
>
>http://psi.somewhere.com/ooxml/attribute(attributeName).html
>
>One modest improvement would be to add version information to that
>string, thus:
>
>http://psi.somewhere.com/odf/1.0/element/(elementName).html

For UBL I'm choosing not to add the version number because our 
mandate covers only minor revisions of UBL 2.0, so only UBL 2.x, and 
within all of UBL 2.x any given construct retains its semantics.

It happens we don't put any business entity in an attribute.

>However, there is a more fundamental problem.
>
>There are attributes with the same names that have different values
>depending upon the element where they appear. This is true for both ODF
>and OOXML. Murata-san assures me this is a very powerful schema design
>feature. I have a less generous opinion of this "feature" but I forebear
>further comment as the schemas are what they are and I can't change that.
>
>So I can't have, for instance:
>
>http://psi.somewhere.com/odf/1.0/attribute/office_name.html
>
>without confusing the different uses of that attribute.

I think you can do with explicitly using "/element/" or "/attribute." 
in the PSI.  If the PSI set is assumed to be for the XML vocabulary, 
then you can probably get away with the following set of files:

http://psi.somewhere.com/odf/1.0/vocabulary/elementName/index.html
http://psi.somewhere.com/odf/1.0/vocabulary/elementName/attributeName/index.html

and the following PSI strings:

http://psi.somewhere.com/odf/1.0/vocabulary/elementName
http://psi.somewhere.com/odf/1.0/vocabulary/elementName/attributeName

which would be resolved in a server to the index.html files.  This 
allows you to have an entire directory in which to put artefacts that 
might be referenced by the PSI documentation (images, etc.).

This addresses attribute context by being in a subdirectory of the 
element subdirectory.  Now there is no ambiguity ... you know exactly 
what the semantics are.  I am assuming, however, that ancestral 
context (beyond parent) is merely addressed in the semantics and is 
not a separate set of semantics.

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.

Note you wouldn't need "/vocabulary/" if the *only* reason you are 
creating PSI strings is for the elements and attributes, but I'm 
guessing there may be other PSI strings related to these 
specifications so this would separate the vocabulary from others.

>The goal of this initial step is to develop a structure for the PSIs and
>then to generate a generous sampling of them to inspect for other
>issues. There are attributes whose behavior varies depending upon the
>presence (or absence) of other attributes either on the same element or
>a parent element but I don't see that as changing the subject in question.

Nor do I ... the semantics for a given attribute include issues of 
the impact of other attributes, but that is just part of its definition.

In my PSI efforts I'm trying to create 2000 PSI pages, one for each 
of the business entities in UBL, to be put in the OASIS PSI server, 
and hyperlink those bidirectionally to 2000 wiki pages in 
http://ubl.xml.org so that the committee manages the formal 
definitions and semantics in the PSI documentation and the community 
supplements that with anything they want to say about each entity in 
the wiki discussion.  From the wiki you can get to the official 
read-only committee specification.  From the committee PSI you can 
get to what the community thinks of a particular concept, how it 
should be used, examples, etc., all of which are not really part of 
the committee-managed semantics.

It turns out the roadblocks are pedestrian concerns about how to 
mount 4000 web pages on two servers.  Once I'm told how I can do 
that, the rest is just a simple matter of stylesheet writing (I've 
done a bit of that before).

I hope this suggestion is considered helpful.  Good luck in your PSI project!

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