Die Endanwender sind davon nicht betroffen, nachdem sie keine Applikationen entwickeln. Das Benutzerinterface, und dazu gehören auch die URIs, welches die Applikationsentwickler oder die Hersteller für den Endanwender vorsehen ist nicht im Scope dieser Schnittstelle. – Abgesehen von notwendigen Applikationsschnittstellen für die Entwickler, wie encodeURL().

Ich sehe hier keinen Widerspruch ob es um Techniker oder Anwender geht. Unser Produkt muss für die Kunden das richtige sein und hier sehe ich sowohl die Entwickler, Systemadministratoren, als auch Anwender und Fachbereiche.

Offene Standards zu unterstützen ist eine der Grundanforderungen unserer Kunden, aber kein Wettbewerbsvorteil. Ein offener Standard ist aber sicher nicht der richtige Ort um Herstellern spezifische Produktfeatures vorzuschreiben.

Wie ein Portal funktioniert, wie die Pageverwaltung aussieht, und wie diese inkl. Berechtigungssystem auf die URIs umgelegt wird, ist implementationsspezifisch und ich kann daran nichts negatives finden. – Hätte der Standard diese URIs vorgeschrieben wäre eure Umsetzung der “beautiful URLs”, wie ihr sie nennt, wohl gar nicht standardkonform umsetzbar gewesen.

ich bin auch der Meinung, dass diese Vorgabe in der Spezifikation stehen sollte und ein Muss ist, sonst passiert es teilweise nicht. Bei Gentics Portal.Node (Java Portal) hatten wir es zuerst auch nicht (weil ja nicht Teil der Spezifikation) und das war ein großer Fehler – haben wir jetzt korrigiert – es gibt das Feature Beautiful URLs .

Aber ich denke wir reden hier über Techniker vs. Anwender Sicht und da ist es wie bei Windows und Google – wer hat da Recht? Ich sage natürlich die Anwender haben Recht und für die muss es passen, weil die müssen schlussendlich damit arbeiten – aber das ist IMHO.

mfg kms

Es gibt durchaus Implementierungen, die eine Konfiguration oder Umsetzung von lesbaren “permanent” URLs zulassen. Es ist aber doch so, dass der render-state mit in der URL kodiert werden muss, sobald der Benutzer etwas daran ändert um genau den Fall abzudecken, dass der Link eben nicht die Bedeutung verliert, wenn er verschickt wird. – Hier widersprechen sich die zwei in Ihrem Posting erwähnten Requirements etwas, nicht?

Ich kann nicht nachvollziehen, wieso der Java Portal Mainstream hier etwas verschlafen haben sollte.