Hello Shane thanks for your kind reply Shane McCarron wrote: > Martin, > > I feel strongly that reliance on the xml namespace attributes as a > prefixing mechanism was a design error, and that we need to fix it > going forward. Thats true I guess... > It is an impediment to adoption of RDFa, and it causes no end of > confusion. Just look at the other messages in this thread where even > the AUTHOR refers to CURIE-referenced vocabularies as namespaces. > They are not namespaces. Namespaces in XML have a very specific > definition, and nothing we have done in RDFa nor with CURIEs conforms > to that definition. But I digress... ..... > > More inline... > > Martin McEvoy wrote: >>> >> Hello Manu Ivan , thank you Manu for documenting this. >> >> Im still a little unsure of why RDFa should support an alternate >> prefixing mechanism, its never a good thing in my view to support >> two ways of doing the same thing? > This is a fair point. Unfortunately, it would be impossible at this > point to remove the current xmlns-based mechanism. We could deprecate > it, and in some mythical future remove it, it that seems the best > course. But we have to remain compatible with our existing base of > users and growing base of documents. >> >> I really do not like the @prefix mechanism at all it seems intuitive >> and a little "hackish". If RDFa really neds to support such a >> mechanism I am more in favour of re-using what we already have and >> not thinking of something new, @content seem ideal for this purpose >> >> <div content="foaf=http://xmlns.com/foaf/0.1/" >> rel="foaf:page" >> typeof="foaf:Document"> > I am not sure why you think that this use of content would convey the > idea of a prefix definition? @content has a specific mean - one of > defining the object for a subject... Thats true in RDFa @content in html/xhtml is just meta data associated with some thing, character data, the contents can be anything, I guess re-using @content is not the best way forward.... > in this case I think you would be producing a triple where some parent > @about set the subject, the relation was foaf:page, and the object was > the string foaf=... with a type annotation of foaf:Document. > I could see trying to define prefixes using our existing mechanisms > and a reserved "rel" value. e.g. <div about="myPrefix" rel="prefix" > resource="http://my.prefix.url/">... but such a mechanism would not > scale to the definition of multiple prefixes on a single element, and > that is a requirement. >> .... >> .... >> </div> >> >> multiple prefixes can also declared in this way eg: >> @content="foaf=http://xmlns.com/foaf/0.1/ >> dct=http://purl.org/dc/terms/". I prefer @content over @prefix >> because authors already know what it means. >> >> I dont believe any of these should be legal >> >> * foo= >> # would this default to the current document? >> >> * =http://someuri.com/ >> # why would you want to overide the default namespace? > Its not a default namespace. That's really really really important > and people just keep forgetting it. Which implies a design error. or just common terminology used by the web at large..... > It is the default prefix mapping for a CURIE. Some people would like > to be able to extend the collection of "reserved" words that are > handled via rel and rev. We have designed mechanisms for that. > Others would like to be able to define a default vocabulary prefix for > a document, so that in the context of a document or the context of an > element un-prefixed CURIEs would be considered in that vocabulary. > This is mainly a means of attracting people who don't like typing > colons, as far as I can tell. I don't mind introducing such a thing, > but feel that extending the collection of reserved values is a more > sensible way to address the problem. And I don't feel that should be > done via @prefix at all. Sound over complex to me not simplifying or correcting anything.... >> >> * xmlns:foo="http://foo.com" @prefix="foo=http://bar.com/" >> # on the same element seems pointless as you cant really >> differentiate the URI's, you cant do that in RDF so why should you be >> able to do that in RDFa? > We need to define a rule if we are permitting both. Would it be silly > to mix them? Of course it would. In my opinion, the rule MUST be > that xmlns: takes precedence. should it? how about if the xmlns:foo="http://bar.com/" was set in the html tag of the document and later somewhere in the content someone used @prefix="foo=http://foo.com/" would xmlns take precedence then? >> >> * I also think this should be Illegal @prefix="audio= >> http://purl.org/media/audio# video = http://purl.org/media/video#" >> # spaces between the "=" equals. > I'm not a big fan of it, but it doesn't hurt anything and Manu and > others felt strongly that users are idiots and the more permissive we > are the less likely it will be that people will get frustrated. I cant imagine that will happen very often but it seems to conflict with the default prefix rule mentioned above ie: =http://someuri.com/ or foo= I guess its not that important, it just makes parsing a little more complex.. >> >> >> Thank you. >> > Best wishes -- Martin McEvoy http://weborganics.co.uk/ "You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive." Dr. James Lovelock, The Ages of GaiaReceived on Friday, 1 May 2009 10:53:27 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 May 2009 10:53:28 GMT