[sc34wg3] Questions on

[Lars Marius Garshol]

* N0398
|
|  =B7 The instanceOf element is now allowed inside the baseName element.

* Murray Altheim
|=20
| In the XTM spec we provided a short description of what each
| subelement means in context. What does <instanceOf> within
| <baseName> mean exactly?  Is this going to be spelled out somewhere
| by in an SC34/WG3 document?

All the semantics are given by the data model. The syntax document
just says how the syntax maps to the data model. See

  <URL: http://www.y12.doe.gov/sgml/sc34/document/0396.htm#sect-topic-name >

The <instanceOf> element there maps to the [type] property on the
topic name item.

Note that N0396 and N0398 were posted prior to the London meeting, so
they are not entirely up to date. I'm working on getting updated
drafts out, but since these have to be according to proper ISO style
this is a lot of work.
=20
* N0398
|
|  =B7 The resourceRef element is now allowed inside the parameters,
|  instanceOf, and roleSpec elements.
=20
* Murray Altheim
|
| Likewise, what does this mean? I think I can guess the first one,
| but this has me a bit stumped. Given our recent discussions on
| topicmapmail, its surprising to see the further expansion of
| <resourceRef>, though if I'm not mistaken about the intent, maybe
| people do want to talk about specific XML elements. XTM could be
| used, e.g., to map an SVG document.  XTM applications should not be
| limited by an inability to reify a particular subject.

What this means is quite simply that you can now can use that element
inside the three elements listed, and that it means the same there as
it does within scope. That is, it's resolved to a topic according to
the procedure in section 3.17 (of N0398)[1]. That's really all.

* N0398
|
| Ed. Note:
| Complete list.
=20
* Murray Altheim
|
| Nice to see only two fairly minor changes.

This is a reminder to the author so that he will remember to make sure
that the list is complete. There will be more changes (the -version-
attribute on <topicMap/>, at least, but possibly even more).

But I agree. We really did try to keep the changes to a minimum.
=20
* Murray Altheim
|
| I also note on
|=20
|  > Issue (xtm-href-whitespace):
|  >
|  > Is whitespace allowed in the xlink:href attribute? If it is allowed,
|  > how is it interpreted? If it is not allowed, what action is taken
|  > when it is found?
|=20
| that the answers given seem a bit confused, as there are two operating
| questions:
|=20
|    Q1: Is whitespace allowed in the xlink:href attribute?
|    Q2: Is whitespace allowed within a URI?
|=20
| where:
|=20
|    A1: The XML rules for attribute value normalization [XML] apply.
|        If the whitespace is at the beginning or end of the attribute
|        value and not in the URI itself, there might be an issue here.
|        But given that the xlink:href attribute is declared CDATA, we
|        don't allow leading or trailing space characters. IMO, there
|        is no reason to make any statement about this in XTM, as it is
|        handled by [XML].
|=20
|          "If the attribute type is not CDATA, then the XML processor must
|           further process the normalized attribute value by discarding any
|           leading and trailing space (#x20) characters, and by replacing
|           sequences of space (#x20) characters by a single space (#x20)
|           character."
|=20
|        But that's not us. We're CDATA.

Agreed. The question is what is allowed *after* whitespace
normalization.
=20
|    A2: RFC 2396 [URI] makes it clear that whitespace is not allowed
|        within a URI and must be escaped. Therefore, any xlink:href
|        attribute values containing whitespace are by definition not
|        conformant with the definition of URI. They are not URIs. I
|        think this is an application-specific issue, but certainly
|        validators that know an attribute value is incorrect should
|        pass that info on to the application. Whether we say anything
|        about it I dunno.

Also agreed, but the problem is that XLink and XML Schema both allow
whitespace in URIs, so we were wondering whether to follow suit. In
the end we decided not to.
=20
| BTW, the links in the TOC don't seem to work. Is that just me?

Nope. See [1].

Thank you very much for this feedback. It's very good to see, though
please do note that both of these documents are out of date. :-(

[1] Direct references broken courtesy of MS Office.

--=20
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >