OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tag-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Namespaces, pseudo- and real

>Really the namespace is a property not of the target but
>of the TA (or a set of TAs). It could be represented as
>a prefix to the TA_Id of each TA of a set of TAs - a
>namespace would then be declared somewhere and associated
>with the prefix.

I object to the use of the term "namespace" in XML for any
purpose other than XML namespaces, especially since the TA
vocabulary in XML may have a real namespace before you're
done with it.

>...Each lab writes its own TAs and
>they have a standard that they should use their urns
>to create namespaces to assign to all TAs they write.

The concept being described here is being discussed as if the
property in question is the "assertor" (I think) whereas the
<normsource> is the spec citation that is the basis for the TA.
It also might be the "TA author" if you think "assertor" is too
strong a term. This concept would be useful while TAs are under
development, if different authors have competing sets of TAs
and the TC wants to keep them organized while deciding which
ones to ratify.

I think the example given brings up some confusion about
whether this pseudo-namespace could be abused to serve as a
surrogate for the class of product (e.g., medium widget), for
which there is another provision in the TA structure.

Then there is this passage:
>...Each TA contains both a TA_Id and (separately for clarity
>and to help with referencing, etc) a namespace. When the TA
>is referenced for a prerequisite then both the TA_Id and
>the namespace are contained in the reference.

That brings to mind the notion that if the spec for technology
Y depends on the spec for X, TAs for Y may directly cite TAs
for X as prerequisites. In other words, the above principle
applies more broadly than just for specs issued by a single TC
for a single technology.

With all the above in mind, I think it's fair to ask:
A. How many different kinds of attribution/reference/citation
   are involved here?
B. Do any of these various notions convey familiar concepts
   such as authorship or authority-to-assert?
C. I define "namespace" as a manifestation of the authority to
   assign names. That's why namespace URIs trace back to names
   in the Domain Name System, which are globally unique. Does
   anything in this scheme involve that authority, other than
   the names of the TA-XML tags themselves?
D. What properties might be needed on TA IDs so that they can
   be referenced from outside their own collection?
E. What outside forces might want to cite a specific TA and
   why? Would we ever get to a state where specs want to cite
   the TAs of previously-standardized technologies rather than
   the specs thereof?

I'm pretty sure that Stephen has identified at least one
situation that justifies having this property on each TA, but
there may be more than one. Please clarify the goals so that
the appropriate name(s) can be assigned.
.................David Marston

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]