Re: Fine-tuning CURIEs (reply #2 :-)

Mark Birbeck wrote:
> Why would I want to use GRDDL?

Not GRDDL in the way you're thinking, but something like hGRDDL that is
a pre-processing step dependent on a @profile and that can be done
entirely in JavaScript.

I want that because it's bad design (and not scalable) to stuff every
ad-hoc standard into the XHTML namespace. That would be much like
replicating the microformat design mistake.

Of course I'm in agreement on the DOM correspondence, no need to go over
that again.

[...]

> In my parser, because I allow non-prefixed values, I would get this:
> 
>   <>
>     <http://www.w3.org/1999/xhtmlEditURI> <http://www.blogg...> .
>   <>
>     <http://www.w3.org/1999/xhtmlservice.post> <http://www.blogg...> .
> 

[...]

> So the question is *only* whether it does any harm for my
> parser to generate these triples, whilst Ivan's parser--for
> example--does not.

We already went through this with the spurious @class triples. I agreed
with you back then that it shouldn't have mattered, but it was
absolutely impossible to convince other folks, and we're going down the
same problematic path here.

So, yes, it does harm, because this will sink our spec with endless
discussion about something with no "right" answer.

> I don't see how it does cause a problem, and I've been quite
> consistent over the last period in trying to ensure that nothing we
> write--whether in the spec or test cases--prevents a parser generating
> more triples than we express in the specification. (I generate triples
> for <img>, <title>, and more, for example.)

Okay, now I'm starting to understand some of the language you wrote in
the Syntax, and I'm not sure it's a good idea to build this kind of
open-endedness into the *spec*.

I don't think a conformant RDFa parser should generate more triples.
That could lead to some really awful implementations that claim to be
"RDFa", but generate tons of random triples, which then it makes RDFa
look completely nuts.

If you want to build a tool that generates other triples, that's no
problem, but I don't think we should be building this into the spec.

> i.e., redefining compact URIs.

This is where it seems you are not thinking in a CURIE-independent way.
I don't think about re-defining CURIEs because they don't exist. They
are being invented in part with this process.

We should do what is right for the XHTML1.1+RDFa community. How it
affects a later draft of CURIEs should not be our concern for now.

> I'm disagreeing because that stops software like mine
> and Operator from having the option of doing stuff with these 'legacy'
> triples.

Why would it prevent software like yours and Operator from trying to
read these other formats? You could even use my proposed hGRDDL (on the
client side!) to do the pre-processing *to* RDFa to give yourself one
processing pipeline.

That said, it shouldn't be a standard part of RDFa, IMO.

> But that doesn't mean I'm saying everyone *must* generate 'legacy'
> triples--only that I want to be able to, and that another way around
> this should be found.

Sure, but building it into the spec is just asking for trouble because
of significant scope creep.

> One approach might be to define what happens to the well-known XHTML
> values in some kind of 'conceptual' pre-processing step--they get
> converted to xh:next, for example--as we have discussed before, but
> then to say that the behaviour for those values that are not
> 'pre-processed' is simply 'undefined'; processors may or may not
> process them...'check with your implementation'...that kind of thing.
> Server-side processors can do what they want, and I can do what I
> want.

I'm not sure where you got the idea that I work on server-side stuff,
what with my bookmarklet implementation :)

I don't think we should leave it open. Whatever is done with legacy
markup is great, but it should not be part of the RDFa specification itself.

-Ben

Received on Friday, 14 September 2007 14:25:14 UTC