[sc34wg3] PSI issue

[Patrick Durusau]

Greetings!

Apologies for the cross-posting but this concerns a proposal I am making 
in WG 5 of SC 34 so I wanted ISO folks to hear this issue as well.

I am trying to design PSIs to represent the markup constructs of both 
ISO 26300 and ISO 29500. Note that I said the "markup constructs" by 
which I mean to eliminate the notion of some uber abstraction that 
represents all "p" elements. Granted that might be an interesting 
exercise and possibly even a useful one but at this point, the only 
subjects of my concern are the elements and attributes as defined by 
those two standards.

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

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.

For example on a draw:draw:area-polygon it specifies a name for an image 
and explicitly need not be unique. On the other hand, when that 
attribute appears on office:annotation, it specifies the name of a 
corresponding <office:annotation> element and the pair must be unique.

One thing that I have considered is having:

http://psi.somewhere.com/odf/1.0/attribute/office_name.html

as a PSI and the information there contains additional PSIs that point 
to the various meanings of that attribute.

I find that attractive because I am sure I will want to talk about 
office:name in "general," that is as a confusing way to specify names on 
elements and at the same time, I will need PSIs to identify the various 
more specific uses of office:name.

Should the more "specific" attributes then have the structure:

http://psi.somewhere.com/odf/1.0/attribute/office_name/element-draw_area-polygon

and

http://psi.somewhere.com/odf/1.0/attribute/office_name/element-office_annotation

???

Be aware that I used the element prefix on the final part of the string 
deliberately because both standards have a tendency to "reuse" names.

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.

Any thoughts or suggestions would be most welcome!

Hope everyone is having a great week!

Patrick



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