OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [tm-pubsubj-comment] Baltimore minutes

Lars Marius

Basically all your comments seem to be valid. See details below. I have
updated the minutes accordingly:

|Section 5, first "point":
|  The namespace http://psi.oasis-open.org has been made available to
|  host PSIs published by OASIS TCs. The physical directory for FTP is
|  in fact http://www.oasis-open.org/committees/tm-pubsubj/psi/ that
|  will not show in the PSIs URLs.
|The second sentence is very hard to understand, and offers several
|possible interpretations that are wrong. I suggest that we remove it,
|since people don't need to know this.

Well, that's what I thought when writing it. I will remove it.

|Section 5, second "point":
|  Discussion on the structure of URLs in that namespace. Two
|  requirements proposed by Steve for the URLs : be as short as
|  possible (but not shorter), and carry certain semantics, so as to be
|  human-friendly. General agreement on that.
|This doesn't really have to do with the minutes, but I think we need
|more rules than just those. 

Certainly, but as few as possible

|For example, the semantics should not vary
|with time (more about this below), and there should be no more
|semantics than absolutely necessary.

The last point seems to be a consequence of "as simple as possible"...
|  For example, GeoLang PSIs for languages should use alpha code in the
|  URL rather than numeric codes.
|ISO 639 does not have numeric codes, so this is not possible. As
|regards ISO 3166, which does have them, we chose to use the numeric
|codes because they were the only ones that were stable.


|Given the choice between stability and memorability I believe we
|should choose stability every single time. In fact, the two are
|fundamentally opposed, because having identifiers that are meaningful
|to humans means there will be reasons to change those identifiers
|based on what they mean to humans. (The ROM -> ROU change in ISO 3166
|is an excellent example of this.) If the identifiers are meaningless,
|on the other hand, this is not a problem.

Yes, we discussed and agreed already on all that in Montréal, in PubSubj
and/or GeoLang, that's why I was a little puzzled by the come back or
"semantics in URLs".

|Section 5, third "point":
|  The structure should also be extensible and usable by other
|  TCs. Making one folder by TC seems the wrong approach, making the
|  URLs longer, and introducing extra unuseful semantics (OASIS is the
|  publishing authority, not the TC).
|Actually, the real reason was that OASIS TCs are ephemeral, and so
|having the TC name in the URI would make the URIs inherently unstable.
|This is an example of unnecessary semantics that vary with time.

Yes. Will fix that in the minutes.

|Section 5, fourth "point":
|  Should directory URLs be used as PSIs, and if yes, for what
|  subjects?
|What Steve says about this matches my memory.


|Section 6, third "point":
|  Discussion about title. Is it to be used as a name of the subject
|  set? "Published Subjects for" could be considered a
|  "machine-readable prefix", the actual name being the rest of the
|  title "Languages in ISO 639"
|This is not a very good fit to my memory of the discussion. I recall
|the "machine-readable prefix" being proposed, but it was not accepted,
|and personally I find it unspeakably repugnant.
|The real issue that was discussed at length was whether including
|"Published Subjects for" in the title would cause difficulty when
|creating a registry of PSI sets, as they would all be named "Published
|Subjects for" this-that-and-the-other.
|We eventually agreed to put "Published subjects for languages in ISO
|639" in the HTML, but I am not sure we reached any conclusion for the
|XTM metadata. Personally I don't think the issue that was raised
|really is worth bothering about.

Well, try to make something consistent of all that in the minutes :(

|Section 6, fifth "point":
|  Discussion about machine-readable metadata. Findable through source
|  code header, need to set an XTM mime type. Suggestion to have some
|  Dublin Core in the header.
|I think instead of "source code header" we should say "LINK elements
|in the HTML HEAD element". Also, it should say "need to register an
|XTM MIME type".


|Section 7:
|  --  IRC meeting Jan 23th 1300 UTC, to try if it works for
|  everyone. Further meetings to be fixed
|  -- F2F meeting at XML Europe London in May. Day to be fixed.
|It's probably worth adding that the agenda for the IRC meeting is to
|schedule the London meeting.

Exact. I had forgotten what the agenda was.

|| I have something that was not clear, neither in my mind, neither in
|| Patrick's notes.
|| What have we decided to be the subject identified by
|| http://psi.oasis-open.org/iso639/
|The PSI set itself. This was decided in the GeoLang meeting. I believe
|PubSubj left it open.

OK. Is not that exactly the point that Mary and you have declared to be
"thick" about? My suggestion is to make it a general recommendation:
when you have a PSI set under http://psi.domain.foo/bar/, it should be
*declared* as the PSI for the set, in the directory index.

See details in the answer to that specific message.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC