Subject: RE: PaceDatePublished: meta-question about other namespaces

From: "David Orchard" <[email-masked]>
Date: Fri, 24 Sep 2004 10:19:34 -0700

I think this is a great set of questions.  Any resolution to this will
make the extensibility and versioning story of Atom much clearer.  The
difference between including the constraint by value (into the atom
namespace) or by reference (referring to the atom namespace) is
definitely important.  I will point out that some schema languages (like
XML Schema) don't deal very well with multiple namespaces, and this may
guide the design of atom.

However, if atom wants something from another namespace and it's
identical, then don't both a) and b) mean the same thing?  

Further, I think the questions are a little more complicated: 
Q: If what atom wants is close but not quite the same as an external
element in a well known namespace, under what conditions should atom
create it's own element versus referring to the element?

Q: If atom chooses to re-use an external element, what should the
granularity of re-use be?  QName + definition?  Local name + definition?
Definition only?  For example, the dcterms:created could be imported
into atom:created with a reference to the dcterms:created definition.

There are advantages and disadvantages to having more "by-value"
definitions than "by-ref" definitions, and the shade of referencing.

Cheers,
Dave
> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Antone Roundy
> Sent: Friday, September 24, 2004 9:16 AM
> To: [email-masked]
> Subject: PaceDatePublished: meta-question about other namespaces
> 
> 
> A meta-question lurking behind this proposal (and PaceDateModified),
> which we've discussed before, but never made a decision on, is what to
> do when we want an element that closely parallels something from
> another well known namespace.  A major reason cited for the rejection
> of PaceDateSubjective (the reason that convinced me) was that a) it
> would be good to have an extension to more comprehensively cover the
> uses addressed by the proposed element, and b) if such an extension is
> built, interoperability will suffer as some people use the core
element
> and some use the extension element.
> 
>  From PaceDatePublished:
> 
>     "Typically, atom:published will be associated with the initial
> creation or first availability of the resource."
> 
> This spans the definitions of a few things from dcterms[1]:
> 
>     dcterms:created: "Date of creation of the resource"
>     dcterms:available: "Date (often a range) that the resource will
> become or did become available"
>     dcterms:issued: "Date of formal issuance (e.g., publication) of
the
> resource"
> 
> If we adopt atom:published, are we going to run into interop issues
> with people who prefer the more tightly defined dates from dcterms?
> 
> So, the meta-question: when considering an element defined in a well
> known namespace, shall we:
> 
> a) Define a deliberately IDENTICAL element in the atom namespace
> b) Define an element in the atom namespace if what we want IS
identical
> to what's defined elsewhere, but refer to the other element if not
> c) Define an element in the atom namespace if what we want IS NOT
> identical to what's defined elsewhere, but refer to the other element
> if it is
> d) Define exactly what WE want in the atom namespace, ignoring the
> existence of the other element (ie. never trouble ourselves to
consider
> elements from other namespaces)
> e) Put nothing in the atom namespace but (a mention of/recommend use
> of) the other element
> 	e1) only if the element is to be optional
> 	e2) and sometimes even make the element required
> f) Put nothing in the atom namespace, and don't mention the other
> element
> g) Consider the question on a case-by-case basis every time
> 
> If we decide to start adopting elements from other namespaces, are we
> going to have to reconsider some elements currently in the spec?  Or
> can we decide that certain elements are so very core to Atom that they
> must be in the atom namespace and/or so entirely sufficient that we
> have no fear of someone going to another namespace for something
> similar because they feel a need for its nuances?
> 
> If we choose a policy for attacking these issues, we should be able to
> speed through a number of decisions much more quickly.
> 
> [1] http://web.resource.org/rss/1.0/modules/dcterms/