Re: Syntax doc comments

Re:
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Oct/att-0481/01-dave.html
You made substantial editoral comments that I'm mostly not dealing
with here, primarily in section 2, which is new, and I expected that.
I indeed hoped for corrections and help in improving the words.

So this mail just responds to the "Technical errors or must fix
comments."  which I see as the priority to deal with, some of which I
need further clarification on before I can understand them and then
decide how to address them.


2 An XML syntax for RDF [[(Informative)]]

I see it as both informative - it tells people how the syntax works
and normative in that it defines such terms as Node Elements,
Property Elements and so on.   I think I've seen support for keeping
it this way, with editorial improvements since it is brand new text.


2.1

[[I see it as a bug that you use the term URIs above without any
qualification or additional text. ]]

Agreed. I am going to change URI to URI-reference throughout, point
to something in RDF-CONCEPTS

2.5

[[False: rdf:type may take a typed or untyped literal or a blank
node. Rephrasing this para to allow for non-standard usage of
rdf:type is hard work. The text also does not account for the case
where two property elements have different xml:lang and so can not
both be compounded on the parent node]]

I will rephrase.

2.7

"RDF/XML uses XML's xml:lang attribute as defined by 2.12 Language
Identification of XML 1.0 [XML] to allow the identification of
content language. This can be added to any XML element"

[[False: XML WG get to specify XML and they say that xml:lang must be
declared in the DTD; RDF/XML permits xml:lang on any element.]]

I will replace with:

  "RDF/XML permits the use of xml:lang attribute as defined by 2.12
  Language Identification of XML 1.0 [XML] to allow the
  identification of content language.  This can be used on any
  node element or property element."


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.


2.11 Omitting Blank Nodes - rdf:parseType="Resource"

"This is done by putting an attribute on the containing property
element rdf:parseType="Resource" ..."

[[ The jena code that uses this production to serialize RDF as XML
does not do it this way; hence a normnative "This is done" is
unacceptable since it makes Jena non conformant. Even an informative
"This is done" is difficult to swallow, given that the only code that
we know of that does this, does not do it this way. The method used
is that you examine the productions you might use, you see whether
the graph you are trying to serialized meets the preconditions and
then you expand the production. Doing it the way you suggest is an
interesting, but very slow exercise.]]

I will replace with "This can be done" since 2.12 also gives another
way to omit blank nodes and this abbreviation remains optional.

(I'll remove "the difficult to read" sentence)


2.12 Omitting Blank Nodes - Property Attributes on an empty Property Element


"If all the property elements on a blank node have string literal
values (or at most one is rdf:type) "

[[False: the actual constraint is significantly more
complicated. variations in xml:lang and non-standard usage of
rdf:type need to be taken into account, also you have forgotten the
at most one occurrence of any property]]

"... , these can be abbreviated by moving them to be property
attributes on the containing property element which is made an empty
element."

I will try to reword and handle these constraints.

Something like

"If all of the property elements on a blank node element have string
literal values with the same in-scope xml:lang value (if present) AND
each of these property elements appears at most once AND there is at
most one rdf:type element with a URI-reference object node, then all
of these property elements ..."

(or list the constraints in a <ul> since this sentence is rather
convoluted)


2.14 Abbreviating URIs - rdf:ID and xml:base

[[and rdf:ID]]

Yes.  Also rdf:bagID with xml:base

"This provides an additional check since the same name can only
appear once in a single RDF/XML document "
[[this is not what you say below, where you permit reuse of a name
with a different xml:base]]

Yes, I'll put in a phrase that the IDs are per xml:base

(where did we get this from?  All I can see is
  
  (3) the scope of xml:base attributes should be taken into account
  when checking for duplicate rdf:ID values
  -- http://www.w3.org/2000/03/rdf-tracking/#rdfms-xml-base
)


2.16 Closed Collections - rdf:parseType="Collection"

"The [[value]] is the collection of nodes given inside"
[[I don't know what value is meant to mean here, but I can't think of
a meaning of value that makes this sentence true.]]

Given there is still debate over if the RDF MT will give some
entailments for these (yes?  no?), I put down something which you are
obviously unhappy with for various reasons.

DAML+OIL defines it even worse, just giving an example without saying
what it does.  Apart from saying "this RDF/XML gives these
N-triples", I need more help with the wording to use here.

Re: closed:

[[the WEBONT folks indicated that 
removing daml:collection would be a problem for them. 
...
As I understand things, the key requirements are:

   o a compact and relatively conventient xml syntax
   o a way to represent a closed collection, i.e. our present understanding 
of issue * rdfms-seq-representation
...
Amongst the possible solutions, the ones I can see are:
   o bless daml:collection as defined as part of RDF
]]
-- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0039.html

which is what we did.


2.17 Reifying Statements - rdf:bagID and rdf:ID

[[ once again you are neglecting the possibility of a change of base URI]]

I'll add that reference for rdf:bagID


5.1 The RDF Namespace

[[This "(no concepts in the graph)" is not what I thought we had
agreed. I thought it was that if you use these terms in a graph,
then: (a) an application may issue warnings and (b) the graph cannot
be serialized in RDF/XML.]]

I've removed that phrase from my later drafts and replaced with:
  Syntax names - not concepts
  Class names
  Property names
  Resource names
-- http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/#section-Namespace

Although really the split could just be Syntax names, other names.


5.2 Identifiers

[[Within RDF/XML, ]]

Yes.

"Blank node Identifiers (labeling nodes)
    These are given local identifiers in the N-Triples serialization
    which MUST match the name production in N-Triples."

    [[This MUST is much too strong. As I remember it, rdf:nodeID can
    expand to an NC_NAME (from namespaces). This is substantially
    more generous than name in NTriples e.g. permitting
    ihWhatsGoingOn . The treatment of mapping everything to Ntriples
    and then to the graph is not a requirement of RDF/XML and so
    there is no requirement to use Ntriple or to meet this
    constraint. ARP does not behave like this. The treatment of
    rdf:nodeID has to be modified to turn the unicode attribute value
    into a unique US-ASCII string for ntriple; but this ugliness is a
    feature of this document, not a feature of RDF/XML; and that
    needs to be clear.]]

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?

(Delete Note: yes)


5.4 Constraints

constraint-nodeID

  "The names used as values of rdf:nodeID come from a set of names
    that are independent of those of rdf:ID and rdf:bagID. The syntax
    of the names must match the rdf-id production

[[There is no constraint here. Any matching use of the production is
valid. This subsection must be deleted, it is currently only a
potential source of confusion. e.g. on first reading I thought you
were saying that rdf:nodeID="foo" and rdf:ID="foo" could not both be
used in the same doc.]]

These words are all directly from WG decisions and reflect what was
asked of us to clarify
  1) The set of names (values of rdf:nodeID) are independent.
  2) The syntax matches the same syntax as rdf-id

Somewhere we have to say 1) - it could be in the rdf:nodeID
production, but that might be too hidden away. 2) may depend on what
you propose as the resolution of your previous comment.

I guess I agree it is not a constraint.

It is also unclear if you mean delete all of 5.4.  If that is the
case, then the restictions on the sets of names of rdf:ID, rdf:bagID
would have to move somewhere else such as in the grammar productions.
They previously were there but that's what Peter Patel-Schneider
originally made his comment was about, and asked that they be pulled
out.


6 Syntax Data Model

"to create the N-Triples"
[[suggest: RDF Graph (no requirement to use N-Triples)]]

I'll replace with "to create the RDF Graph" (link to RDF-CONCEPTS section)
and same later in same paragraph.

"The N-Triples[[ suggest: arcs]] may be generated in any order"

I'll replace with

"The RDF graph arcs (N-Triples) may be generated in any order"


6.1.2 Element Event

"language
    Set from the *attributes* as described above. If no value is
    given from the attributes, the value is set to the value of the
    language accessor on the parent event (either a Root Event or an
    Element Event), which may be undefined."
   [[ no, the way you've done it doesn't it have to be at least the empty string? ]]

Will change to "...which may be the empty string".


6.1.4 Attribute Event


"string-value
    set to the value of the attribute information item property
    [normalized value] as specified by ..."

[[Do we need to discuss the problems of whether we do XML validation
or not. The attrbite value normalization rules are different for
validated XML or non-validated XML? [XML]]]

    ... (if an attribute whose normalized value
    is a zero-length string, then the string-value is also a
    zero-length string). "

This is more of a comment.  Do you want me to change or point to
something here?  Add something to RDF-CONCEPTS and point to it, point
ot the normalization section there?


6.1.7 Literal Event

"If *literal-language* is empty[[ the empty string ]]"

Yes.


7.2.1 Grammar start


"Note that if such embedding occurs, the grammar may be entered
several times but no state is expected to be preserved."
[[ This contradicts other statements that talk about things with scope
RDF/XML document. e.g. constraint-id.]]

So should I say more or less?
More:

   "...times; only outer document-scoped state is expected to be
   preserved such as restrictions on the set of names for rdf:ID,
   rdf:bagID as defined in SECTION constraint-id, the in-scope base
   URI and the in-scope xml:lang"

Less:
   Say nothing.


7.2.4 Production propertyElementURIs
7.2.5 Production propertyAttributeURIs

[[We never disallowed rdf:nil did we?]]

We didn't micro-decide everything, I asked one, got no replies so
made a choice.  rdf:nil is a sentinel, we can either:
   1) not encourage its use as a class or property and forbid it everywhere
   2) not care, and allow it everywhere.

Do you want to change to 2) ?


7.2.18 Production parseTypeOtherPropertyElt


"All rdf:parseType attribute values other than the strings "Resource",
"Literal" or "Collection" are treated as if the value was
"Literal". Processing  MUST ..."

[[ This MUST is incorrect - this processing is entirely optional,
what MUST be achieved is an effect as if this processing was done,
e.g. a first parse that replaced any unrecognised rdf:parseType
attribute value with "Literal" is conformant. Suggest delete MUST]]

"... continue at production parseTypeLiteralPropertyElt. No extra triples
are generated for other rdf:parseType values.

I did eliminate this grammar production once, only allowing the legal
values but I had to add it back since M&S clearly says:

  [[Other values of parseType are reserved for future specification
  by RDF. With RDF 1.0 other values must be treated as identical to
  'Literal'.]] -- http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/

and this is not optional.


7.2.33 Production rdf-id


"An attribute *string-value* matching any legal [XML] token Nmtoken"
[[This incorrectly permits q:name as an rdf:id. Suggest use NC_NAME
from namespaces.]]

Yes.


8 Serializing an RDF Graph to RDF/XML

[[Suggest: use of NCName in text as well as href.]]

Yes.


Dave

Received on Wednesday, 30 October 2002 09:10:09 UTC