Re: <code> element and scripting languages

1. (esp. for mr Gannon Dick) is there any room left for an extension subtag, as defined by BCP-47 at section 2.2.6? I.e. is such a definition of any value, and could "programming" language be registered according to that procedure?

No.  Not IMHO.  It chains the new additions to the old lessons.  What you would really like to do - and I think it is admirable - is to propagate a culture of data interoperability, that's what Standards are for. It is proactive "style" for coders, that which will never depreciate.

2. if the answer is negative, and/or if BCP-47 is such an unreliable standard, what are we left with? Could <code> benefit from the @language attribute as it was (uncanonically and uselessly) defined on <script> elements? <code language="whatever"> would leave all the issues about translation and peech
 recognition unsolved, but it would be a good point for programming language detection. Why hasn't it ever been proposed?

What you are "left with" is what you had before the IETF reinvented a more agile wheel which in some cases are more fragile than agile.  Language as in character set is useful information for tagging code, and interesting to a coder audience.

You have two choices:
1) You can take the MIME types and create an acronym repository with "permanent" names for scripting languages.  There may already be a PURL for this, ok, three choices.  The ID servers at the US Library of Congress has a formal scheme - http://id.loc.gov/vocabulary/languages/zxx

2) You can go for broke.  If people who write scripts are a culture unto themselves, then register the audience and see who says "that's for me". (http://id.loc.gov/vocabulary/organizations.html)  This is the only reliable way to avoid capture, land grabs, etc. of your "organization" once it prospers.  It might also help to write a strategic plan (http://xml.fido.gov/stratml/) with periodic automatic updates.  There is a reason why standards making organizations move with deliberation and it is not as they claim consensus building. Moving slowly, with authority takes all the fun out of the "Embrace, Extend, Extinguish" cycle.

--Gannon
--------------------------------------------
On Tue, 3/17/15, Andrea Rendine <master.skywalker.88@gmail.com> wrote:

 Subject: Re: <code> element and scripting languages
 To: "Gannon Dick" <gannon_dick@yahoo.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>
 Date: Tuesday, March 17, 2015, 7:45 PM
 
 I know
 this discussion will bring me nowhere, so this message is
 just a reply.Yes, what I want is an indication, not the
 exact MIME type associated to the scripting language. Which
 would be useless, since even if I have <code
 language="application/xml"> for example,
 it's just plain text to be identified for search engines
 and maybe for syntax highlighting, UA speech syntesizers,
 translation tools. Code is neither to be executed nor
 evaluated. It's just to be set apart from any other
 text, because it's basically not normal text in a normal
 language. And while I have read more about Best Current
 Practices and I understand it's all about using language
 codes *specifically* on the Internet, it's just what is
 needed for this particular purpose (and it is the specific
 standard referred to by the spec - and last but not least,
 it's now something like 6 year old. Is its
 implementation still so controversial?).
 If you have read other answers to
 the thread, you saw that some authors use data-* attributes
 and this is unacceptable. Using class as suggested by the
 spec, however, is terrible as well because every standard is
 missing and class has no syntax value (as well as
 interfering with CSS selector). @lang, on the other hand, is
 not only semantically "valuable" (we are still
 talking about a form of identifying textual expression
 means), but also technically correct - consider that CSS3
 has a specific selector for lang property (not only value,
 as it applies to an element with a @lang, as well as its
 descendants without a different @lang).These are
 my final points: 1. (esp. for mr Gannon Dick) is
 there any room left for an extension subtag, as defined by
 BCP-47 at section 2.2.6? I.e. is such a definition of any
 value, and could "programming" language be
 registered according to that procedure? 2. if
 the answer is negative, and/or if BCP-47 is such an
 unreliable standard, what are we left with? Could
 <code> benefit from the @language attribute as it was
 (uncanonically and uselessly) defined on <script>
 elements? <code language="whatever"> would
 leave all the issues about translation and speech
 recognition unsolved, but it would be a good point for
 programming language detection. Why hasn't it ever been
 proposed?
 Thanks to
 anybody willing to
 contribute.

Received on Friday, 20 March 2015 17:56:08 UTC