Re: some notes on (

At 03:26 PM 9/7/98 +0200, Olivier MARCE wrote:

>1- Last example in section 2.2.2 has a syntax error : <s:Person>
>is closed by </rdf:Person>

thanks; I have added this to the errata page [WD-Errata], linked
from the Document Status.

>2- in section 5, there is no restriction on the number of propObj, propName,
>value for a node wich is instance of Property.

good point.  I raised this with the Working Group, proposing that
we add explicit constraints for this case.  The WG yesterday
approved this addition.

>3- In section 6, paragraph on properties ("Within property, the URI...") 
>states that "If an expression is specified..."
>It is not clear for me what is an "expression" in this context.

I will try to clarify this in the next draft.  We have used "expression"
and "RDF expression" generally to mean "content with XML markup" and
"content with RDF/XML markup".  This paragraph was intending to say
that if a property value was something other than an atomic string
(we will use the term 'literal' instead of 'atomic string' in the
next draft) then it must be a portion of an RDF graph, and the actual
value of the property was then the root node of that subgraph.

>4- In section 6, in paragraph refering to productions 6.3 and 6.10, 
>and in paragraph refering to productions 6.10.
>Sentence beginning with "Specifically.." exclude some specific attributs
>of the set of triple creator attributes (ID, about, aboutEach, bagID).
>The attribute "xml:lang" should be excluded too, 

yes, I will add this to the next draft.

> and more generaly, 
>all attributes begining with "xml" (e.g. xmlns...)

attributes beginning with xmlns should certainly follow the same
rule but I am reluctant to make a general rule for all attributes
beginning with 'xml'.  Since we don't know what future attributes
may be defined in the XML namespace, we can't anticipate what
the most preferred representation in an RDF graph might be.  But
to exclude them from the graph completely would mean that there
was no opportunity for an RDF 1.0 client to ever be told how to
process a document that contained this new feature.  I prefer to
take the risk that the default interpretation (as another property)
will be useful in some cases and harmful in no cases.

>5- as far as I understand, bagId is used for referecing Description sets only. 
>Why don't use "descId" instead of the confusing "bagId" ?

The Working Group has discussed the name of this attribute several
times.  But I raised your comment again with the group to assertain
the current feelings.  Objections were raised that "desc" is not a
word -- and the obvious expansion of the attribute to "descriptionID"
was unpalatable.  The WG has decided to retain the current name.

It is a tiny rationalization, but the possibility exists that at
some future time we may find other places where two identifiers
are needed in a single element tag and where one of the resources
being identified is of type Bag.  Keeping the generic 'bagID' name
allows for the possiblity of reusing it elsewhere.

Thank you for your comments on the draft -- they have been most

-Ralph R. Swick

Received on Wednesday, 30 September 1998 11:25:13 UTC