Little by little I am trying to learn Semantic Mediawiki almost like in a tutorial. I got so save info (including uri, titles and tags) for each element of a list using subobjects and then to get the list of the tag.
This is the wiki page with the list of the tags: link
Now I'd like to further explore the articles related to each tag. For example, is it possible to list the articles having the tag x? I wonder if it would be a nice idea to create a Module to parse the output of the semantic query.
SemanticMediawiki: embed some property into a piece of text
Can I use Semantic Mediawiki to add properties to each element of a list?
MediaWiki Semantic Template: Property "" (as page type) with input value contains invalid characters or is incomplete can cause unexpected results
Semantic Mediawiki error: processing error text "#category " cannot be used as a property name in this wiki
Semantic Mediawiki: writing a query that returns all the suboject defined in a page
Semantic Mediawiki: aggregation similar to SQL GROUP BY like #ask query
Best solution here is to make use of array extension.
Create an array containing all tags, and make it unique to have a "distinct list".
Then print your array, and run an ask query for each tag in the print loop, with the count format .
{{#arraydefine:tags| {{#ask:[[-Has subobject::{{FULLPAGENAME}}]] |?Tags#-=| mainlabel=-|limit = 1000}} |,|unique}}
{{#arrayprint:tags|, |####|<nowiki/>
[[####]] ({{#ask:[[Tags::####]]|format=count}})
}}
This code will print a link to each page named as tag value, and print the number of subobjects that hold this tag. Even if the solution is not optimal, as you are running a lot of independent queries, you should not have performance issues unless you have very high traffic on your wiki.
Nota bene : The best practice is to create a specific template for tag pages, one that list all articles having the tag. With the Page Forms extension, you can create each page automatically with this template, simply by running the job queue.
I'd like to refer to a specific part of a web page which I am not the author of, and which is not tagged with the NAME attribute. The specification of the part I have in mind could be made, e.g., as the location a certain word appears, and which could be manually reached via a FIND operation. I imagine something like
http://somesite.com#search-for:foo-bar
Is there some feature in HTML allowing for this?
No.
You can only link to elements with an id and a elements with a name.
Let's say I have a Wikidata item QID Q19675, and want to get the name of that item in Spanish within the wikicode of an unrelated Mediawiki page.
While getting a property like P281 postal code is easy (just write {{#property:P281|from=Q19675}}), how to get the name, which for some reason is not a normal property?
Unlike this question, this time I am not looking for a REST API, but for a Mediawiki wikicode expression.
You can use the Lua function mw.wikibase.label to get the label in the local language. If you're on a wiki that has a copy of the Wikidata template Label (e.g. the English Wikipedia), you can use that directly: {{label|Q19675}}.
If you want the label in a language other than local, use mw.wikibase.entity:getLabel.
Is there a standard format that allows for multiple parameters to be specified in the URI fragment? (the part after the hash #, not the query string.)
The most related information would be this question: Multiple fragment identifiers correct in URL?. The allowed characters for fragments can be found in that question as well.
Would it be acceptable to use, for instance, a semicolon to delimit multiple parameters like this:
http://example.net/page.html?q=1#param1=foo;param2=bar
Are there any unintentional behaviours that I should be aware of with this method? What if there is no such ID in the document with the value param1?
For the purposes of this question, only URIs of HTML resources are considered.
I think you should read this: http://en.wikipedia.org/wiki/Fragment_identifier#Examples
So the de-facto standard format for multiple parameters should be #param1=value1¶m2=value2
You can see this way is used by Media Fragments URI 1.0 and by PDF documents. There seems to be no standard for HTML resources though as you can parse the fragment in JavaScript in any way you like. But I'd use the same format as it looks more natural being similar to the query string format. If the browser cannot find any element with id/name equal to your hash fragment, it will navigate to the beginning of the document by default.
Also browsers will consider the complete hash fragment as a possible id/name. So they will look for id/name equal to param1=value1¶m2=value2 but not just param1.
I have a PHP script that will generate <input>s dynamically, so I was wondering if I needed to filter any characters in the name attribute.
I know that the name has to start with a letter, but I don't know any other rules. I figure square brackets must be allowed, since PHP uses these to create arrays from form data. How about parentheses? Spaces?
Note, that not all characters are submitted for name attributes of form fields (even when using POST)!
White-space characters are trimmed and inner white-space characters as well the character . are replaced by _.
(Tested in Chrome 23, Firefox 13 and Internet Explorer 9, all Win7.)
Any character you can include in an [X]HTML file is fine to put in an <input name>. As Allain's comment says, <input name> is defined as containing CDATA, so the only things you can't put in there are the control codes and invalid codepoints that the underlying standard (SGML or XML) disallows.
Allain quoted W3 from the HTML4 spec:
Note. The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire ISO10646 character set.
However this isn't really true in practice.
The theory is that application/x-www-form-urlencoded data doesn't have a mechanism to specify an encoding for the form's names or values, so using non-ASCII characters in either is “not specified” as working and you should use POSTed multipart/form-data instead.
Unfortunately, in the real world, no browser specifies an encoding for fields even when it theoretically could, in the subpart headers of a multipart/form-data POST request body. (I believe Mozilla tried to implement it once, but backed out as it broke servers.)
And no browser implements the astonishingly complex and ugly RFC2231 standard that would be necessary to insert encoded non-ASCII field names into the multipart's subpart headers. In any case, the HTML spec that defines multipart/form-data doesn't directly say that RFC2231 should be used, and, again, it would break servers if you tried.
So the reality of the situation is there is no way to know what encoding is being used for the names and values in a form submission, no matter what type of form it is. What browsers will do with field names and values that contain non-ASCII characters is the same for GET and both types of POST form: it encodes them using the encoding the page containing the form used. Non-ASCII GET form names are no more broken than everything else.
DLH:
So name has a different data type for than it does for other elements?
Actually the only element whose name attribute is not CDATA is <meta>. See the HTML4 spec's attribute list for all the different uses of name; it's an overloaded attribute name, having many different meanings on the different elements. This is generally considered a bad thing.
However, typically these days you would avoid name except on form fields (where it's a control name) and param (where it's a plugin-specific parameter identifier). That's only two meanings to grapple with. The old-school use of name for identifying elements like <form> or <a> on the page should be avoided (use id instead).
The only real restriction on what characters can appear in form control names is when a form is submitted with GET
"The "get" method restricts form data set values to ASCII characters." reference
There's a good thread on it here.
While Allain's comment did answer OP's direct question and bobince provided some brilliant in-depth information, I believe many people come here seeking answer to more specific question: "Can I use a dot character in form's input name attribute?"
As this thread came up as first result when I searched for this knowledge I guessed I may as well share what I found.
Firstly, Matthias' claimed that:
character . are replaced by _
This is untrue. I don't know if browser's actually did this kind of operation back in 2013 - though, I doubt that. Browsers send dot characters as they are(talking about POST data)! You can check it in developer tools of any decent browser.
Please, notice that tiny little comment by abluejelly, that probably is missed by many:
I'd like to note that this is a server-specific thing, not a browser thing. Tested on Win7 FF3/3.5/31, IE5/7/8/9/10/Edge, Chrome39, and Safari Windows 5, and all of them sent " test this.stuff" (four leading spaces) as the name in POST to the ASP.NET dev server bundled with VS2012.
I checked it with Apache HTTP server(v2.4.25) and indeed input name like "foo.bar" is changed to "foo_bar". But in a name like "foo[foo.bar]" that dot is not replaced by _!
My conclusion: You can use dots but I wouldn't use it as this may lead to some unexpected behaviours depending on HTTP server used.
Do you mean the id and name attributes of the HTML input tag?
If so, I'd be very tempted to restrict (or convert) allowed "input" name characters into only a-z (A-Z), 0-9 and a limited range of punctuation (".", ",", etc.), if only to limit the potential for XSS exploits, etc.
Additionally, why let the user control any aspect of the input tag? (Might it not ultimately be easier from a validation perspective to keep the input tag names are 'custom_1', 'custom_2', etc. and then map these as required.)