Re: Syntax doc comments

Thanks Dave for your fast turn around.

I'll try and clarify my unclear comments.

I guess I should note continuing unhappiness at your insistence that section
2 is normative. I do not believe we should publish like that (maybe it's
just as well that I won't be at the telecon).

Most of your msg is acceptable to me, thanks for accepting many of my
comments. I would prefer major surgery.

<<
2.8

"the object node labelled with XML content beginning a:Collection"
[[False: suggest change example.]]

(Apart from labelled, which I will remove)

I don't understand this problem, you will have to explain further
what is wrong here and tell me what is needed in an example.
>>

The problem is that the XML content in the example begins with whitespace.
There is widespread misunderstanding about how whitespace is treated in
RDF/XML, and careless phrasing will add to that. I suggest ensuring that
there is no whitespace between the two relevant tags in the example.

2.16 Closed Collections - rdf:parseType="Collection"

I think you have not understood my point.
This section 2 starts the document.
The terminology you use has not been introduced.
The word "closed" comes out of the blue. Is it "closed" like a closed door,
or a closed and unreasonable lover?

I don't think we want to describe what closed means, or what we were trying
to do, or why - just what we have done. Thus all I would like to see is the
XML and the triples - never apologize, never explain.

The amount of text required to give an adequate explanation of this
production is very large, and you will certainly hit the semantic issues
which we are still struggling with. Don't go there, save your time, and save
me my time correcting you.

5.1 The RDF Namespace
sounds OK, but I might come back to this on the next review cycle.

<<
I can't convert this comment into an obvious change.  If I require
N-Triples to explain how RDF/XML maps to the RDF graph, and N-Triples
has syntax restrictions, what do I fix?
>>

I see brian has picked up on this one too.
One, somewhat cludgy way of fixing it is to define an escape sequence from
NC_NAME to Ntriple-NAME - would something like encode an NC_NAME in UTF-8
and then base64 encoding do it? (I don't really know what base64 encoding
is, so I am speaking out of the wrong orifice!) The mapping just needs to
give a unique Ntriple Name for each NC-NAME, since both sets are infinite
there are lots of these mappings.

constraint-nodeID
The bit I was suggesting deleting was the bit labelled constraint-nodeID.
It is referred to in just one place, (the nodeidAttr production) where
deleting the reference leaves has no impact.
i.e. this paragraph is technically redundant - the grammar with this
constraint is identical (accepts the same strings and assigns them to the
same graphs) as the grammar without this constraint.
The constraint-ID paragraph on the other hand, is necessary; and it is nice
having it called out separately.

(I had to look back at the doc I sent - I made a mess with the end tags
didn't I - you must have patched up your copy)


XML validation and attribute normalization

We are claiming that we are done with the technical issues - but this is one
that we have yet to resolve (in my view). I guess we should escalate to
Brian.


Not reached 7.2.1 Grammar start
(will do tomorrow)

Jeremy

Received on Wednesday, 30 October 2002 15:04:46 UTC