Re: Why bound prefixes are an anti-pattern in language design

On Tue, 11 Aug 2009, Elias Torres wrote:
> > 
> > > > [reverse DNS identifiers and URIs]
> > > 
> > > All of my intro simply to say that it's really confusing when you 
> > > say stuff like: "I included both". I think this part is really the 
> > > crux of the matter. You should be consistent and suggest something 
> > > because you have data or real past user experience to prove it's 
> > > better and not include "both" to leave things up to personal taste.
> > 
> > For some things -- e.g. identifying Web pages -- URIs are clearly 
> > preferable. For others -- e.g. predicates -- shorter strings are IMHO 
> > preferable. I don't see a problem with having both.
> 
> Clearly nobody is arguing using URIs for identifying Web pages. But I 
> believe you were talking about predicates and allowing the use of both 
> URIs and reverse DNS identifiers. I hope you don't miss my main point in 
> the last email.
> 
> http://dev.w3.org/html5/spec/Overview.html#selecting-names-when-defining-vocabularies
> 
> Maybe I'm simply raising the issue that Microdata should only allow one 
> type of name since you and others mention many tangible and 
> personal-taste issues with URIs, I think that it might be easy to prove 
> that less options that effectively do the same as in your example, the 
> better. Kind like Perl's !@#$~,.;- vs Python's whitespace.

I agree, but one of our goals is to have at least a first approximation of 
compatibility with existing RDF vocabularies, and they use URIs. Allowing 
URIs is one of those things that ends up being included because of the 
guideline of being as simple as possible, but no simpler -- here, being 
simpler still would lead to the language not addressing the use cases it 
set out to address.


> For instance, if Jon and Adam both write content at example.com, at 
> http://example.com/jon/... and http://example.com/adam/... respectively, 
> then they could select identifiers of the form "com.example.jon.name" 
> and "com.example.adam.name" respectively.

Sure, they can do that today.


> > > I thought HTML5 was about not making the mistakes of the past. If 
> > > you leave this up to choice, then maybe we need RDFa AND Microdata 
> > > in HTML5 so people can choose, but obviously I believe that would be 
> > > mistake (without even thinking of which one is right or better).
> > 
> > We _do_ have RDFa and Microdata, and people _can_ chose. I don't see a 
> > problem with this.
> 
> Do you really see this as the long run solution in HTML5 to have/allow 
> both?

Long term I expect other languages to be introduced also. I certainly 
don't expect the Web to shrink in terms of what technologies are used.


> In other words, is Microdata here to stay? Would we waste time by trying 
> to find out which option has been adopted the most in let's say 3 years, 
> easier to use, blah blah in order to drop one or the other?

If Microdata is not a successful technology, then it will be dropped, 
regardless of what happens with other technologies. I can't speak for the 
group working on RDFa.


> > > I've been watching all of this prefix discussion around RDFa hoping 
> > > to see an improvement on CURIE, but nothing jumps out yet. One 
> > > obvious choice is not to have them at all and keep identifiers 
> > > small.
> > 
> > That's my preferred solution also.
> 
> I'm not speaking on behalf of the RDFa TF, but simply wondering if 
> CURIEs/prefixing would be out of RDFa, what other issues would you have 
> with RDFa today? (sorry for invoking the Lazy-Ian-Web, since I know you 
> have stated them before). Of course, this might matter depending on your 
> answer to the previous question (are both specs staying?).

As you say, I've given more elaborate responses on this before. Off-hand, 
though, some of the other parts of RDFa I think are a problem are the 
overall complexity, and the reliance on URIs for everything. For example, 
regarding complexity: RDFa uses a whole bunch of attributes where only a 
very few are necessary. It shouldn't be possible to declare more than one 
triple per element (unless there is no limit at all). Similarly, I haven't 
seen a use case for per-value data typing.


On Wed, 12 Aug 2009, Martin McEvoy wrote:
> 
> Is this the reason *why* xmlns prefixes are not supported in HTML 5....
> 
> ".... The DOM Level 2 does not support any mechanism to resolve 
> namespace prefixes. For all of these reasons, use of such entities and 
> entity references should be avoided or used with extreme care. A future 
> Level of the DOM may include some additional support for handling 
> these."
> 
> http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations

No. "xmlns" in general isn't in HTML5 for several reasons, primarily the 
problems I've described with namespaces, and because of compatibility 
concerns with legacy Web content that has "xmlns" attributes already.


On Wed, 12 Aug 2009, Danny Ayers wrote:
> 2009/8/12 Ian Hickson <ian@hixie.ch>:
> 
> > Microdata is more resilient to this behaviour than RDFa. This is not 
> > an accident, it is a design decision. I believe it is a prerequisite 
> > for this kind of technology: where we can make our languages resilient 
> > to copy-and-paste, we must do so.
> 
> Do you mean resilience in this sense:
> [[
> In computer networking: “Resilience is the ability to provide and
> maintain an acceptable level of service in the face of faults and
> challenges to normal operation.”
> ]] http://en.wikipedia.org/wiki/Resilience_(network)
> ?

I meant resilient in the sense that if an author copies some content from 
one HTML document to another, the meaning is preserved.


> If so, I'd suggest that making allowances for spec-naive copy & paste 
> operations is unlikely to provide an acceptable level of service in the 
> context of embedded data.

It's certainly less likely to be successful than copying, say, a single 
form control, but it's probably not less likely to be successful than 
copying a whole form, which is relatively common. It's likely to be far 
more successful if it doesn't involve having to copy content from various 
parts of the document.


> When an author wishes to communicate information in a given medium, they 
> need awareness of how the medium will be interpreted.

That would be nice. It's common for that to be missing on the Web, though.


> In practise I think this means a strict interpretation mechanism is 
> desirable at the statement level, but with ignore-if-fail, so the 
> information communicated by documents (and their embedded data) can be 
> maximally conveyed. I reckon this is generally consistent with the rest 
> of HTML5 design.
> 
> Thing is, I'm not sure the microdata spec in its current form can 
> support this, while the RDFa approach almost certainly can. Remember 
> looser interpretation should be (and in both cases is) possible further 
> down the chain, depending on the client application.

I don't see any material difference between RDFa and Microdata that would 
make one or the other more able to support what you describe, other than 
Microdata's self-contained nature (not using prefixes) making Microdata 
somewhat less susceptible to accidental changes in meaning.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'