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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: Re: Namespaces, pseudo- and real


This posting to the comment list by David highlights
the possibility that there may be several namespace-like
properties of TAs or TA_Ids which might have to be
modeled. This adds to my feeling that the TA ID is best
modeled as a complex rather than simple type. Then it
can be extended, perhaps by custom extension implementations.

Not that it applies strictly to TAs, but with CCTS-based
models the ID datatypes share several metadata-like
properties/attributes which include scheme, schemeAgency
and the like. So these kinds of metadata may not be too
difficult to identify for the TA model. e.g. 'agency'
may be one of them and perhaps 'agencyId', this being the
agency assigning the namespace and/or maybe the Id.

(Above use of terms 'namespace' and 'metadata' have a
different context here to the usual one for TAs - i.e.
not context of XML or test cases respectively.)
-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting david_marston@us.ibm.com:

>> 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]