On 9/26/12 4:33 PM, Christopher Brooks wrote:
...
>> However, unless you're using the latest tooling, the semantics are
>> lost anyways (meaning they have to be handled manually- they still
>
> This would be my point - you generally don't get the URI to parse it,
> just to match it, so that it is really a unique identifier and nothing
> more. Parsers won't look at it for version info to decide if their
> knowledge of the 1.2.1 version should allow them to parse the 1.2.0
> version. The parser just sees that the two are different.
Yep. I just like the idea of meaning, even if only potential meaning.
Most parsers will only get true/false regardless of which route is
chosen, but the human /could/ get this rich set of information in
addition (and eventually the parsers may take advantage as well).
Dates == time + unknown change, but what is important is what changed,
vs. amount of time between something changing. Was it a big change? A
little change? How likely will it be that more of my things need
changing to get back in sync? A date doesn't convey much.
>> I'm partial to the blah:blah:blah:1.0 type of deal because it's short,
>
> I have concern that the version number will be confused with the
> Matterhorn version number, which is unrelated. E.g. if you see
> urn:X-opencast:engage:1.2 and you are using a 1.3 server you might
> think there is a problem when there is really no difference.
Down this path lies madness! :)
Dependency hell is a problem inherent to computing. It is one of the
Hard Things (the other two are naming stuff, cache invalidation, and
off-by-one errors). Modularization, schema versions, and the rest are
attempts by humans to help humans, leveraging computers.
Unless we don't really want to be modular, there is no way of getting
around different versions for different things. What about API vs.
implementation version? Keep them in sync so folks don't get confused?,
etc. and so forth and so on. -- We're not doing anyone any favors by
making things harder in the long run, just so they appear easier to the
inexperienced at first blush.
First blush is important, but it is not the end, or even close to the
end, by definition. As simple as possible but not simpler, &c. (Heh.
I sound silly. "Welcome to the church of den!" ;])
> I'm fine with changing the date to dashes, though I don't know which
> xpath tools you are using that will be breaking on namespaces with \'s,
> the W3C uses them everywhere....
Breaking on such would be less than useful! :)
This is purely about style, and parsers which don't handle namespaces
well (not all xpath implementations were created equal), and how it
looks when you're adding xmlns manually along with search paths (as far
as namespaces go, jboss's have been my favorite to work with-- but don't
get me started on namespaces w/XML. Bah! ;]).
We are using "abstract" namespaces, so the web-like /'s look weird to my
eye, plus there's the whole using dates vs version numbers bit. :)
If we version the XML, every new version will be a breaking change
parser-wise, whichever way, right?
If we're going to version, let's use something more meaningful than
dates. And I think the question of "if" is worth thinking about. Being
practical is sometimes smarter than being smart, as it were.
:Denny
--
Everyone has a fair turn to be as great as he pleases.
Jeremy Collier
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
