Re: Re: minutes of 1998-10-27 call

Ron,

Thank you for your comments regarding the RDF Model and Syntax
specification.

Per your suggestion, wording has been incorporated into the
specification, excluding "canonicalization of Unicode characters" as
recommended by Martin Duerst.

Sincerely,

Ralph Swick, W3C Metadata Activity Leader
Eric Miller, Bob Schloss, RDF Model and Syntax Chairs


> Message-ID: <0D611E39F997D0119F9100A0C931315C2E0D8D@datafusionnt1>
> From: Ron Daniel <RDaniel@DATAFUSION.net>
> To: "'Ralph R. Swick'" <swick@w3.org>, w3c-rdf-syntax-wg@w3.org
> Date: Thu, 29 Oct 1998 11:56:42 -0800
> Subject: RE: minutes of 1998-10-27 call
>
> Ralph says:
>
> > >Ron says that Ralph's proposal looks OK, but does not address his
> > >concern
> > >about the spec not defining what is to be done with the
> > "non-understood
> > >RDF" content.
> >
> > We did add a mechanism to be able (in the future) to say that a
> > certain subset of the markup "generates no tuples" [Section 6.].
> > Are you saying that these words need to be changed?  Or are you
> > saying that the RDF specification should mandate a certain
> > representation for a property value that has markup?
> >
> > I think we might be able to clarify what it means to "generate no
> > tuples" but I feel it is inappropriate for RDF to state a specific
> > value representation.  We need to be better informed by the DOM
> > and XML Infoset work items before we consider whether anything
> > more is needed in RDF than what will be said by those groups.
> >
> > (I intend to comment separately on your "sorry to bring this up"
> > message.  [Daniel0050])
> >
> [Ron Daniel]
> The point I raised was the one you answered in that
> other message - what CAN I do with the stuff that
> is in an 'unknown RDF' element.
>
> The real requirement here is dealing with marked-up
> strings that are not significant to RDF. If there is a
> mechanism for that, good, then this is not a show-stopper
> objection. I raised it only because I thought we were going
> to be using the 'unknown RDF' escape mechanism to deal with
> XML, and if that were the case, the spec would need to say how
> those strings would be handled, not only how the would not be
> handled.
>
> > >Direction to the editors, parseType=Literal, an example, and a
caveat
> > >about all the stuff not being handled in the first version
> > (whitespace
> > >canonicalization, attributes, interactions with 8 billion other
> > >XML applications and namespaces, ...)
> >
> > I think I understand those directions up to the 8 billion part.
> > Would someone suggest the sort of words you would like to see
> > in the specification that convey this caveat, please?
> >
> [Ron Daniel]  this was stuff that had been mentioned in a
> few places during the call. Here's some rough material that
> I think conveys the gist of the point:
>
> The working group producing this draft agrees that the
> parseType='Literal' mechanism is a minimal-level solution to the
> problem of allowing RDF descriptions to contain values which
> have XML markup. However, XML has a number of complexities and this
> mechanism may or may not adequately deal with all of those
complexities.
> Some exmaple complexities are issues around canonicalization of
> whitespace, canonicalization of Unicode characters, etc. More
generally,
> the W3C is actively developing a family of interacting specifications
> around XML. Idioms for handling
> the interactions between the specifications have not yet developed. As

> a particular example, an alternative solution to the problem of
> embedding marked-up strings was proposed that extended the XML
> namespace mechanism. In the future, that particular proposal may
become
> a common way of dealing with interactions between W3C specifications,
> but at the time this specification was developed the techical opinon
of
> the working group was that it was a safer, though less powerful
> approach,
> to use the parseType='literal' mechanism. Future versions of this
> specification
> may provide additional approaches.
>

Received on Wednesday, 25 November 1998 14:42:05 UTC