W3C home > Mailing lists > Public > public-grddl-wg@w3.org > November 2006

Re: fixed GRDDL formal rules...

From: Danny Ayers <danny.ayers@gmail.com>
Date: Wed, 8 Nov 2006 12:19:04 +0100
Message-ID: <1f2ed5cd0611080319m20938ae3x591ac44c6ee8e1b@mail.gmail.com>
To: "Murray Maloney" <murray@muzmo.com>
Cc: "GRDDL Working Group" <public-grddl-wg@w3.org>

On 07/11/06, Murray Maloney <murray@muzmo.com> wrote:
> At 12:38 PM 11/7/2006 -0600, Dan Connolly wrote:
> >If rev 1.155 of section 2 is clear, I can try something like that in
> >section 3.
> I am able to follow the normative parts of Section 2, with or without the
> examples.


If an information resource IR has an XML representation whose root
element has a namespace name NS and for any TX, the resource
identified by NS  has a GRDDL result that is the merge of { ?NSDOC
<http://www.w3.org/2003/g/data-view#namespaceTransformation>  ?TX }
with any other RDF graphs, then TX is a GRDDL transformation of IR

Seems essentially ok, though as suggested "subgraph" may be clearer,
along the lines of "...GRDDL result that contains a subgraph with the
pattern { ?NSDOC
<http://www.w3.org/2003/g/data-view#namespaceTransformation>  ?TX }".

It also seems a little confusing having "a GRDDL result that is the
merge..." alongside "TX is a GRDDL transformation". Dunno, maybe we
need a bit of terminology to help distinguish between what you might
call *the* GRDDL result (as in what you get from applying all
mechanisms/transformations) and *a* GRDDL result (pre-merge sub-result
coming from a single transformation/mechanism).

I'm curious - anyone know of any (ideally normative) docs anywhere
that include special-casing of the root element, or similar post-mime
mechanisms to determine doc type? I think the approach is plenty good
enough for this revision of the spec, but there may prove to be cases
that are unnecessarily unGRDDLable and/or lead to unnecessary

Take for example XHTML used as Atom content. If XHTML has a GRDDL
profile defined, but Atom doesn't, then any embedded RDF is
unreachable. If Atom does have a profile, and its desirable to make
the XHTML-encoded RDF available, based on the root element namespace
mechanism then unless I'm missing something there would need to be an
additional mechanism to enable further nose-following to get to the
XHTML transformations from the Atom definition. (It's not possible for
the Atom profile to reference every possible content type, any
namespaced XML can go in).



Received on Wednesday, 8 November 2006 11:19:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:09 UTC