| At line 88 changed 5 lines |
| Quoting Janne Jalkanen <janne.jalkanen@iki.fi>: |
| [...] |
| [Hide Quoted Text] |
| It needs a proper metadata API... I don't particularly want to |
| introduce anything new that would break anyway soon. |
| Quoting Janne Jalkanen <janne.jalkanen@iki.fi>:\\ |
| [...]\\ |
| It needs a proper metadata API... I don't particularly want to\\ |
| introduce anything new that would break anyway soon.\\ |
| At line 94 changed 5 lines |
| However, there are quite a few people over on this list who *are* |
| interested in proper metadata stuff. I'd recommend that you kick off |
| a task force to write up a requirements list (this is the same way as |
| auth got implemented: Andrew wrote a really good requirements list, |
| and I gave him direct CVS access to write the code, too ;-) |
| However, there are quite a few people over on this list who *are*\\ |
| interested in proper metadata stuff. I'd recommend that you kick off\\ |
| a task force to write up a requirements list (this is the same way as\\ |
| auth got implemented: Andrew wrote a really good requirements list,\\ |
| and I gave him direct CVS access to write the code, too ;-)\\ |
| At line 100 changed 2 lines |
| Murray or someone else, if you're willing to lead this task force, |
| that'd be great. Or, if someone wants to start to maintain 2.4. and |
| Murray or someone else, if you're willing to lead this task force,\\ |
| that'd be great. Or, if someone wants to start to maintain 2.4. and\\ |
| At line 184 added 20 lines |
|
|
| ---- |
|
| I'm not too hot on doing localization at page level - I can see it resulting in more trouble than what it's worth. |
|
| There's one minor error in your thinking, and it's that you're thinking about ''metadata of pages''. This is slightly incorrect. JSR-170 is more generic, as it exposes everything as ''properties of nodes''. While in most cases there is not much difference, granted, this means that technically speaking, the page content itself is metadata ''of the node'', and so is everything else, such as the author, etc. |
|
| The JSR-170 notation actually comes from XML, so therefore {{{dc:contributor}}} is correct in our sense :-). |
|
| But, before we go any deeper into this, we need to enumerate the properties that we need, and how the repository (or, if you will, the DOM) should be built before jumping into the intricacies of Dublin Core, though. Once the properties are enumerated and analyzed, we can then figure out if we have anything in Dublin Core that we can use. For example, the [RFC 4287|http://www.ietf.org/rfc/rfc4287] might be also an useful source of syntax. |
|
| Let's not decide on implementation before requirements. |
|
| --JanneJalkanen, 20-Jun-2007 |
|
| Janne, I think you're misinterpreting me on a couple of counts. I'm not talking about doing localization at a page level, I'm talking about designing a metadata API that ''permits'' multiple languages for any given metadata field. DC does that abstractly, and concretely in some of its syntaxes. And no, I'm not thinking about the metadata of pages, but of nodes (basically, the metadata needs to be applicable as you suggest at any level — no issue there, things need to permit recursivity in the design as well as syntactically), and I'll stress that the colon at this point is not necessarily what we'd use since we haven't figured out whether (a) whether we're talking about abstract or concrete syntax or (b) whether the property names will show up in the implentation as XML element type names or as attribute values; in the latter case, no, we'd not see colons. In the former, ''only if'' we use XML Namespaces (where 'dc' is the namespace prefix). But as you say, let's not talk about that kind of detail until we've figured the requirements. I'm only enumerating the Dublin Core properties in the abstract sense at this point. How they get referred to will depend on implementation. |
|
| -- MurrayAltheim, 21-Jun-2007 |
|
