W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2003

Issue xmlsch-11 "layering on xml" proposal to close

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Thu, 24 Apr 2003 12:35:26 +0100
To: w3c-rdfcore-wg@w3.org
Message-ID: <1479.1051184126@hoth.ilrt.bris.ac.uk>


I'm sure this'll need some more rewording.

Dave
---

Summary: reject

The comment raised in
http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html
in the depths of section 4.4

[[
    As regards the approach taken to defining the syntax, in our view,
    layering of specs has very high value, and so defining an XML document
    type by way of what is very nearly a character-level BNF is at best a
    missed opportunity and at worst a serious mistake. It obscures the
    important aspects of the document type behind a welter of irrelevant
    detail about e.g. whitespace and start-tag/end-tag matching. It makes
    it very difficult for the reader to actually understand what is and
    isn't actually allowed -- what an RDF/XML document actually looks
    like.

    Not only does this confuse levels and thus readers, it also runs the
    risk of inadvertently defining an XML subset. It also appears, on a
    strict reading, to rule out XML documents not derived from the parsing
    of character streams as possible RDF/XML (so that it would be
    illegitimate to regard a data structure created using a DOM interface,
    for example, as RDF/XML).

    The use of event-triggered data-model construction actions to specify
    the relationship between XML representation and corresponding data
    objects is innovative and compelling, but surely it would be
    straight-forward to associate these events with a pre-order traversal
    of an infoset independently constrained by a DTD, XML Schema schema or
    other appropriate definition of the canonical document type. If
    continued support for alternative forms is considered essential, then
    a two-step approach where the semantics of any non-canonical form is
    defined in terms of a canonical form to which it corresponds would
    still be far simpler than the current approach.
]]



[[
The RDF Core WG has considered your last call comment captured in

   http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-11

(raised in section
 "4.4. Normative specification of XML grammar (policy, substantive)" of
http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html )

and decided

   URL-HERE

to reject it.


The main points you raised in this comment are:

1) RDF/XML is defined in "what is very nearly a character-level BNF
  [which] is at best a missed opportunity and at worst a serious
  mistake." 
    - obscuring important parts of the document type
    - making it very difficult for the reader to actually
      understand what is and isn't actually allowed.
    - confusing layers

RDF/XML is entirely layered on the XML Infoset as defined in
  Syntax Data Model
  http://www.w3.org/TR/rdf-syntax-grammar/#section-Data-Model
and is not defined at the character-level.

All XML detail is handled by the XML specifications, not this
document - deployed RDF/XML applications are entirely built on
standard XML tools.  In layering on the XML infoset, we leave only
the important parts of RDF/XML that users and application writers
need be concerned about - elements, attributes, whitespace and text.

It would have been a mistake to gloss over where, say, the whitespace
was significant and where it was ignored - which was one problem with
the original RDF M&S specification.


2) Rules out XML documents not parsed from character streams (such as DOM)

This was explicitly called out:
  [[
    This model illustrates one way to create a representation of an
    RDF Graph from an RDF/XML document. It does not mandate any
    implementation method - any other method that results in a
    representation of the same RDF Graph may be used.

    In particular:
    ...
	* This specification does not require the use of [XPATH] or [SAX2]
  ]]
  http://www.w3.org/TR/rdf-syntax-grammar/#section-Data-Model

If a DOM interface can provide the very few (4) XML Infoset Infoitems
that are needed here, it is not ruled out.


3) Suggests a two-step approach first mapping to canonical RDF form
   constrained by DTD or XML Schema

An approach using a mapping to a canonical RDF written in XML is
related to issue xmslch-10 where we explain why we didn't feel we
could do this under the current charter.  We it certainly would have
been useful and helped.

The model and grammar used here closely matches how many RDF/XML apps
were written, in a token matching style that can be used with
standard syntax lexers and grammar generators.  This approach has
proved suitable after other implementor feedback.

]]
Received on Thursday, 24 April 2003 07:36:22 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:57:00 EDT