 |
 |
"John A. Kunze" wrote: > How should we name our canonical Date scheme (the W3C profile of ISO8601)? I vote for "WTN8601"! Here is my comments re pros and cons: > Choices: > -------- > > 1. Continue using the name ISO8601 to refer to our profile of ISO8601, > as defined in the W3C Technical Note [2]. > > CONS: > ----- > - calls something ISO8601 that isn't ISO8601; agents that only parse > the profile will incorrectly believe they can't process the element > > - to distinguish real ISO8601, a new name needs to be invented, e.g., > > scheme = "REAL_ISO8601" > > - co-opting the term "ISO8601" will create real political trouble with > the ISO directorate; esp. bad if DC wishes to win acceptance there Well put. > PROS: > ----- > + installed base argument -- doesn't disturb existing collections dchtml isn't (yet :-) a legacy system. Any use of it at the present time must be by fairly active development teams. It shouldn't be too painful at this stage for them to do a s/ISO8601/WTN8601/g or similar. > + software and people who use DC will "know what we mean" anyway In any system, name space pollution at one point becomes a problem. The "you know what I mean"-argument brings it to that point sooner. > + full ISO8601 may be unimplementably complex and never exist anyway Well, people some people has actually managed to create parsers for all the perverse ways you can write an email-address (i.e. all legal addresses as specified in RFC822) -- so I wouldn't rule that out completely :-) . > + if we co-opt "ISO8601" early, our subset meaning should prevail Maybe, maybe mot. Early adoption is not the only way to score a home run in the standardization game. > 2. Discontinue using "ISO8601" to mean our profile; use "WTN8601" instead. > > (PROS & CONS: reverse above lists, change names, get totally confused... > > 3. Discontinue using "ISO8601" to mean our profile; use a new name instead. > > (Propose a new name other than "WTN8601".) > > 4. None of the above. > > (PROS & CONS: please give your reasoning) If we say "ISO8601" we should mean "ISO8601" -- all of it. However, adopting all of ISO 8601 is probably not a very good idea. There is lot of excess baggage in there that we can and should do without. IMHO ISO8601 suffers from the same disease that killed ISO/OSI as an interconnection standard: too many options, setting the stage for non- interworking implementations. The W3C profile makes a lot more sense from an implementation viewpoint. So we choose to use that, and we should make that choice apparent and unambiguous through our choice of name for that particular scheme. (Beside that, what to use is already defined in RFC2413. It says clearly to use the W3C technical note on Data and Time Formats, so the debate on what to use is moot.) Overloading a different meaning (a specific W3C Technical Note profiling ISO 8601) on the apparently unambiguous distinguished name "ISO8601" is a IMHO a completely no-no when we are creating standards. If we preserve in using the distinguished name "ISO8601", somebody will eventually look up the ISO standard and use it as a reference when they are marking up their collection. Inevitable, some of these will home in on parts that the WTN8601 profile never reach. The idea of having a process before something becomes a standard is to be able to change things that is not optimal. Anyone who implements something before things are frozen must know that things can and will change, and must be willing to accommodate that in his or her implementation and data. -- - gisle hannemyr ( [log in to unmask] - http://home.sol.no/home/gisle/ ) ------------------------------------------------------------------------ "Use the Source, Luke. Use the Source." -- apologies to Obi-Wan Kenobi ------------------------------------------------------------------------ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%