I will be out of the office Monday 7/23 - Friday 7/27.

 -dls-

>>> "[log in to unmask]" 07/26/07 05:49 >>>

Hi Mikael,

Thanks very much for this. It looks really good. Apologies for the delay
in responding.

A few thoughts/comments, all of which are pretty minor, I think, and
some of which I think are really just a reflection of the fact that, as
you say, this is still a work-in-progress:

3. Introduction
===============

> A DSP does not address the following:
> * Human-readable documentation.

I did wonder whether there might be some way of accommodating
human-readable stuff too, i.e. allow "annotation" of Description
templates, Statement Templates etc, kind of in the way W3C XML Schema
allows "annotation" to be "attached" to definitions/declarations. That
way an instance of the DSP XML format could be used as the source of
(more or less) the whole of what we've in the past called a DCAP i.e.
including the human-readable guidelines. I don't think this is an
absolute requirement, BTW. Just wondered if it was feasible. If the
answer is that you want to focus on gettig the structural stuff done
and/or it makes things too complicated, that's fine ;-)

4. Basic Structure
===================

I was wondering whether the model should include classes/entity types
for "Literal Value Surrogate Constraints" and "Non-Literal Value
Surrogate Constraints".

At first I thought this might be introducing some redundancy because you
already subclass/subtype the two categories of "Statement Template", but
OTOH, I think you do make essentially that distinction in 8.5 and 8.6,
right? i.e. 8.5 and 8.6 deal specifically with constraints on the value
surrogate part of the statement, excluding the property URI.

Also I wondered whether introducing those two "intermediate" entities
might make it easier to define one set of "value string constraints"
which can then be referred to within the "literal value surrogate
constraints" and the "non-literal value surrogate constraints" (in the
latter case supplemented by the minOccurs/maxOccurs).

(Urgh, sorry, that's hard to describe without drawing a picture! Maybe
it's fine as it is!)
 
6. Usage examples
=================

(a) This is just a presentational thing (and a personsl preference at
that!), but I would prefer to see the definitions/descriptions of the
different sorts of constraints before the examples i.e. current sections
7/8 before section 6 (or have examples included alongside each
definition/description). However it's presented, I think there needs to
be a clearer association between the markup conventions and the
constraint types.

(b) We should probably try to align the namimg conventions used in the
DSP XML format with those used in whatever format we end up with for
representing DC description sets in XML e.g. use of "VES" or
"vocabEncSheme" etc. Even if the names use different XML Namespaces
(which they probably should), I think it would be helpful to aim for
some consistency in the "local parts" of the names.

Most of the rest of my comments are just minor word-smithing, I think...

7. Description Templates
========================

Possible omission: Should there be a constraint which allows a DSP to
specify whether a "Described Resource URI" is
required/optional/prohibited? (cf. 8.6.3.1 for Value URI)

7.1 Identifier

> A string that can be used in a Value Constraint to reference a
description template that applies to the value resource.

I think this applies specifically to the Non-Literal Value case (i.e.
8.6 rather than 8.5), so probably worth making that explicit here?

> A string that is used to identify a Description Template, so that it
can be referenced in a Non-Literal Value Constraint as a description
template that applies to the value resource.

7.3. Minimum occurrence constraint

The "allowed values" are "non-zero integer", but the default value is
zero. I think there's a contradiction there?

I think we do probably want to allow for minOccurs=0 (i.e. a description
matching tis template is optional), and for people to explicitly state
the default if they want to, so I think the "allowed values" should just
be "integer" (or "non-negative integer")?

7.5 Resource Class Membership Constraint

> Classes that the resource may be an instance of

I _think_ the intent here is that the resource _must_ be an instance of
one of the classes listed, right? If so, I'm not sure that "may" quite
captures that: the current phrasing suggests (to me) that it is optional
for the resource to be an instance of one of the classes listed - which
isn't really a constraint at all! ;-)

So I think this needs to say something like:

> A list of classes at least one of which the described resource must be
an instance of.

(Urgh. Something like that!)

8. Statement Templates
======================

8.1. Minimum occurrence constraint

Similar argument as for 7.3, I think? i.e. I think the "allowed values"
should just be "integer" (or "non-negative integer")?

8.4.1. Property list constraint

> A set of properties that are allowed in this statement template.

Very minor nitpick, but we should probably settle on a consistent
wording to describe the various list constraints e.g. "Properties
that...." or "A list of properties that..." or "A set of properties
that...."

8.5.1. Literal list constraint

> a list of literals, i.e. (string, language tag) or (string, syntax
encoding scheme URI) pairs.

Plain literals don't require a language tag, right? So a list of
literals might include literals that are just "strings"?

8.5.2. Literal language constraint

> "mandatory" / "optional" / "disallowed"

The convention used in W3C XML Schema to describe these three options in
analogous situations is, I think, "required"/"optional"/"prohibited".
Obviously we don't have to follow that, but it might make life a bit
easier for people who are doing both DSP and W3C XML Schema if we did.

8.6.1. Description template reference

> Default: Related description not allowed

I probably need to think about this a bit more, but I wondered whether
this was a bit too restrictive... But maybe it's OK as it stands.

Thinking out loud:

I think this says that either (a) my ST references a DT, in which case
my statement must refer to a ("related") description of the value which
matches that DT or (b) my ST does not reference a DT, in which case my
statement must not refer to a ("related") description of the value.

So I was wondering about the case where I want a description of the
value to be optional i.e. my DSP says, in descriptions of widgets, a
statement referring to the dc:creator property is required
(minOccurs=1), and you can either provide a value string or you can
provide a description of the creator. My interpretation of the current
doc (which may be wrong!) is that I can't specify that. The closest I
could get, I think, would be to provide two Statement Templates, both
for the dc:creator property, one referring to a DT for an agent (the
value), and the other not referring to a DT. But I don't think I could
say that one or other of those STs must be matched.

Maybe that's OK - and I take your point that you aren't trying to cover
every possible constraint, or combination of constrints, and more
complex stuff could be done at the syntactic level - I just wanted to
check that my interpretatation was correct.

8.6.2. Class membership constraint

Similar argument as for 7.5, should say something like

> A list of classes at least one of which the value must be an instance
of.

8.6.3.2. Value URI list constraint

> If a value URI is given, it must be taken from this list. Cannot be
specified if value occurrence is "disallowed"

I think that should say

> If a value URI is given, it must be taken from this list. Cannot be
specified if value URI occurrence is "disallowed"

8.6.5.1. Minimum occurrence constraint

Similar argument as for 7.3, I think? i.e. I think the "allowed values"
should just be "integer" (or "non-negative integer")?

9. XML Syntax

Very minor point, but re XML attribute names minOccur/maxOccur, W3C XML
Schema uses the names minOccurs/maxOccurs (with a trailing "s"), so
it'll probably be helpful to align with that. I can imagine people
working across both will keep making mistakes otherwise - I know I
would! ;-)

Cheers

Pete
---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
Weblog: http://efoundations.typepad.com/efoundations/
Email: [log in to unmask]
Tel: +44 (0)1225 474323