Technical Advisory Board (TAB)

 View Only
  • 1.  agreement on URN-based namespaces?

    Posted 10-12-2010 13:19
    The version .01 draft of merged-3x-TNG [now OASIS
    Naming Directives] flagged the rule about URNs
    for identifying XML namespaces with question-mark. [1]
    
    But we did not discuss in the meeting whether it
    should be (in that draft) "deprecated" in the sense
    of "not recommended" or "disallowed" [where TAB F2F
    minutes said "deprecated"]
    
    I'd like to remove doubt by getting agreement now, if
    possible, that a reasonable compromise might be
    to require HTML scheme URIs for all new development
    efforts (e.g, in new TCs), but to allow continued
    of URNs by TCs that currently use URNs, in both
    [1] specifications under development (not-yet OS
    or terminal CS) and [2] new deliverables that are
    part of a recognized family of specifications, e.g.,
    in a new Profile specification what will become
    "published profile specification #4 in an open-ended
    seried of pofiles".
    
    If there's agreement on that concept about where
    URNs are allowed and disallowed, then I just need
    to settle on wording.
    
    Does anyone disagree with what's formulated above?
    
    If not, does this wording work (trying to use "must" or "may"
    according to requests)
    
    [suggested]:
    
    URN-based XML namespaces may be used by existing TCs
    for specifications currently under development and
    for future deliverables belong to a family of
    closely related specifications where architectural
    considerations require use of URNs.  URN-based
    XML namespaces must not be used otherwise because
    they lack a standard, ubiquitous resolution method
    using DNS[+HTTP].
    
    - Robin
    
    [1] version .01 merged-3x-TNG text was:
    
    URN-based XML namespaces are also allowed for current
    specification development efforts, but are not
    recommended [ /* | are disallowed */ !!] otherwise,
    as they lack a standard, ubiquitous resolution method
    using DNS[+HTTP]
    
    
    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio: http://www.oasis-open.org/who/staff.php#cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter: http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783
    
    


  • 2.  Re: agreement on URN-based namespaces?

    Posted 10-12-2010 13:21
    Correction (sorry):
    
    s/HTML scheme URIs/HTTP scheme URIs/
    
    -rcc
    
    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio: http://www.oasis-open.org/who/staff.php#cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter: http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783
    
    
    On Tue, 12 Oct 2010, Robin Cover wrote:
    
    > The version .01 draft of merged-3x-TNG [now OASIS
    > Naming Directives] flagged the rule about URNs
    > for identifying XML namespaces with question-mark. [1]
    >
    > But we did not discuss in the meeting whether it
    > should be (in that draft) "deprecated" in the sense
    > of "not recommended" or "disallowed" [where TAB F2F
    > minutes said "deprecated"]
    >
    > I'd like to remove doubt by getting agreement now, if
    > possible, that a reasonable compromise might be
    > to require HTML scheme URIs for all new development
    > efforts (e.g, in new TCs), but to allow continued
    > of URNs by TCs that currently use URNs, in both
    > [1] specifications under development (not-yet OS
    > or terminal CS) and [2] new deliverables that are
    > part of a recognized family of specifications, e.g.,
    > in a new Profile specification what will become
    > "published profile specification #4 in an open-ended
    > seried of pofiles".
    >
    > If there's agreement on that concept about where
    > URNs are allowed and disallowed, then I just need
    > to settle on wording.
    >
    > Does anyone disagree with what's formulated above?
    >
    > If not, does this wording work (trying to use "must" or "may"
    > according to requests)
    >
    > [suggested]:
    >
    > URN-based XML namespaces may be used by existing TCs
    > for specifications currently under development and
    > for future deliverables belong to a family of
    > closely related specifications where architectural
    > considerations require use of URNs.  URN-based
    > XML namespaces must not be used otherwise because
    > they lack a standard, ubiquitous resolution method
    > using DNS[+HTTP].
    >
    > - Robin
    >
    > [1] version .01 merged-3x-TNG text was:
    >
    > URN-based XML namespaces are also allowed for current
    > specification development efforts, but are not
    > recommended [ /* | are disallowed */ !!] otherwise,
    > as they lack a standard, ubiquitous resolution method
    > using DNS[+HTTP]
    >
    >
    > Robin Cover
    > OASIS, Director of Information Services
    > Editor, Cover Pages and XML Daily Newslink
    > Email: robin@oasis-open.org
    > Staff bio: http://www.oasis-open.org/who/staff.php#cover
    > Cover Pages: http://xml.coverpages.org/
    > Newsletter: http://xml.coverpages.org/newsletterArchive.html
    > Tel: +1 972-296-1783
    >
    >
    


  • 3.  need re-wording on suggested text for URNs [Re: agreement on URN-basednamespaces?]

    Posted 10-12-2010 13:33
    I already realized there's a flaw in the
    language "may be used".  For the moment, please just consider
    whether you have any disagreement on the point that
    new TCs must not mint URN-based XML Namespaces, but
    current TCs may.  The best word for "mint" is tricky,
    and "use" is incorrect because some specs create
    a table of prominent XML namespaces "used" in the
    specifications, sometimes with prefixes, where
    some of these XML namespaces are defined/declared
    in other specifications (incl other SSOs/SDOs), and
    are only "used" (made use of) in the subject specification.
    
    -rcc
    
    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio: http://www.oasis-open.org/who/staff.php#cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter: http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783
    
    
    On Tue, 12 Oct 2010, Robin Cover wrote:
    
    > The version .01 draft of merged-3x-TNG [now OASIS
    > Naming Directives] flagged the rule about URNs
    > for identifying XML namespaces with question-mark. [1]
    >
    > But we did not discuss in the meeting whether it
    > should be (in that draft) "deprecated" in the sense
    > of "not recommended" or "disallowed" [where TAB F2F
    > minutes said "deprecated"]
    >
    > I'd like to remove doubt by getting agreement now, if
    > possible, that a reasonable compromise might be
    > to require HTML scheme URIs for all new development
    > efforts (e.g, in new TCs), but to allow continued
    > of URNs by TCs that currently use URNs, in both
    > [1] specifications under development (not-yet OS
    > or terminal CS) and [2] new deliverables that are
    > part of a recognized family of specifications, e.g.,
    > in a new Profile specification what will become
    > "published profile specification #4 in an open-ended
    > seried of pofiles".
    >
    > If there's agreement on that concept about where
    > URNs are allowed and disallowed, then I just need
    > to settle on wording.
    >
    > Does anyone disagree with what's formulated above?
    >
    > If not, does this wording work (trying to use "must" or "may"
    > according to requests)
    >
    > [suggested]:
    >
    > URN-based XML namespaces may be used by existing TCs
    > for specifications currently under development and
    > for future deliverables belong to a family of
    > closely related specifications where architectural
    > considerations require use of URNs.  URN-based
    > XML namespaces must not be used otherwise because
    > they lack a standard, ubiquitous resolution method
    > using DNS[+HTTP].
    >
    > - Robin
    >
    > [1] version .01 merged-3x-TNG text was:
    >
    > URN-based XML namespaces are also allowed for current
    > specification development efforts, but are not
    > recommended [ /* | are disallowed */ !!] otherwise,
    > as they lack a standard, ubiquitous resolution method
    > using DNS[+HTTP]
    >
    >
    > Robin Cover
    > OASIS, Director of Information Services
    > Editor, Cover Pages and XML Daily Newslink
    > Email: robin@oasis-open.org
    > Staff bio: http://www.oasis-open.org/who/staff.php#cover
    > Cover Pages: http://xml.coverpages.org/
    > Newsletter: http://xml.coverpages.org/newsletterArchive.html
    > Tel: +1 972-296-1783
    >
    >
    


  • 4.  wording on suggested text for URNs [Re: agreement on URN-basednamespaces?]

    Posted 10-12-2010 14:15
    Here is revised text on the matter of URNs as XML namespaces
    being [dis]allowed and under what conditions. It replaces
    the imprecise and probably misleading /use/ with /declar/,
    following what seems to be reasonable industry practice [1],
    and provides continuity with the (a) existing NG, where I
    used /declar/ and (b) the current template which uses
    the heading "Declared XML Namespaces:"  But formally, the
    thing "declared" using the attribute is a namespace binding.
    Since "Namespaces in XML 1.0 (Third Edition)" [2] uses
    /declar/, I think it's reasonable to follow...
    
    Candidate replacement text, if the rule in principle is
    to be accepted:
    
    URN-based XML namespaces may be declared by existing TCs
    in specifications currently under development and
    in future deliverables belong to a family of
    closely related specifications where architectural
    considerations require use of URNs.  URN-based
    XML namespaces must not be declared otherwise because
    they lack a standard, ubiquitous resolution method
    using DNS[+HTTP].
    
    -rcc
    
    [1] some authors talk about "defining" an XML namespace, while
         others use "declaring"; specifications "introduce" new
         XML namespaces via declarations
    
    [2] Declaring Namespaces
         http://www.w3.org/TR/REC-xml-names/#ns-decl
    
    
    On Tue, 12 Oct 2010, Robin Cover wrote:
    
    > I already realized there's a flaw in the
    > language "may be used".  For the moment, please just consider
    > whether you have any disagreement on the point that
    > new TCs must not mint URN-based XML Namespaces, but
    > current TCs may.  The best word for "mint" is tricky,
    > and "use" is incorrect because some specs create
    > a table of prominent XML namespaces "used" in the
    > specifications, sometimes with prefixes, where
    > some of these XML namespaces are defined/declared
    > in other specifications (incl other SSOs/SDOs), and
    > are only "used" (made use of) in the subject specification.
    >
    > -rcc
    >
    > Robin Cover
    > OASIS, Director of Information Services
    > Editor, Cover Pages and XML Daily Newslink
    > Email: robin@oasis-open.org
    > Staff bio: http://www.oasis-open.org/who/staff.php#cover
    > Cover Pages: http://xml.coverpages.org/
    > Newsletter: http://xml.coverpages.org/newsletterArchive.html
    > Tel: +1 972-296-1783
    >
    >
    > On Tue, 12 Oct 2010, Robin Cover wrote:
    >
    >> The version .01 draft of merged-3x-TNG [now OASIS
    >> Naming Directives] flagged the rule about URNs
    >> for identifying XML namespaces with question-mark. [1]
    >> 
    >> But we did not discuss in the meeting whether it
    >> should be (in that draft) "deprecated" in the sense
    >> of "not recommended" or "disallowed" [where TAB F2F
    >> minutes said "deprecated"]
    >> 
    >> I'd like to remove doubt by getting agreement now, if
    >> possible, that a reasonable compromise might be
    >> to require HTML scheme URIs for all new development
    >> efforts (e.g, in new TCs), but to allow continued
    >> of URNs by TCs that currently use URNs, in both
    >> [1] specifications under development (not-yet OS
    >> or terminal CS) and [2] new deliverables that are
    >> part of a recognized family of specifications, e.g.,
    >> in a new Profile specification what will become
    >> "published profile specification #4 in an open-ended
    >> seried of pofiles".
    >> 
    >> If there's agreement on that concept about where
    >> URNs are allowed and disallowed, then I just need
    >> to settle on wording.
    >> 
    >> Does anyone disagree with what's formulated above?
    >> 
    >> If not, does this wording work (trying to use "must" or "may"
    >> according to requests)
    >> 
    >> [suggested]:
    >> 
    >> URN-based XML namespaces may be used by existing TCs
    >> for specifications currently under development and
    >> for future deliverables belong to a family of
    >> closely related specifications where architectural
    >> considerations require use of URNs.  URN-based
    >> XML namespaces must not be used otherwise because
    >> they lack a standard, ubiquitous resolution method
    >> using DNS[+HTTP].
    >> 
    >> - Robin
    >> 
    >> [1] version .01 merged-3x-TNG text was:
    >> 
    >> URN-based XML namespaces are also allowed for current
    >> specification development efforts, but are not
    >> recommended [ /* | are disallowed */ !!] otherwise,
    >> as they lack a standard, ubiquitous resolution method
    >> using DNS[+HTTP]
    >> 
    >> 
    >> Robin Cover
    >> OASIS, Director of Information Services
    >> Editor, Cover Pages and XML Daily Newslink
    >> Email: robin@oasis-open.org
    >> Staff bio: http://www.oasis-open.org/who/staff.php#cover
    >> Cover Pages: http://xml.coverpages.org/
    >> Newsletter: http://xml.coverpages.org/newsletterArchive.html
    >> Tel: +1 972-296-1783
    >> 
    >> 
    >
    


  • 5.  Re: [tab] agreement on URN-based namespaces?

    Posted 10-12-2010 15:31
    +1
    
    Mary 
    
    
    
    
    On Oct 12, 2010, at 9:19 AM, Robin Cover wrote:
    
    > The version .01 draft of merged-3x-TNG [now OASIS
    > Naming Directives] flagged the rule about URNs
    > for identifying XML namespaces with question-mark. [1]
    > 
    > But we did not discuss in the meeting whether it
    > should be (in that draft) "deprecated" in the sense
    > of "not recommended" or "disallowed" [where TAB F2F
    > minutes said "deprecated"]
    > 
    > I'd like to remove doubt by getting agreement now, if
    > possible, that a reasonable compromise might be
    > to require HTML scheme URIs for all new development
    > efforts (e.g, in new TCs), but to allow continued
    > of URNs by TCs that currently use URNs, in both
    > [1] specifications under development (not-yet OS
    > or terminal CS) and [2] new deliverables that are
    > part of a recognized family of specifications, e.g.,
    > in a new Profile specification what will become
    > "published profile specification #4 in an open-ended
    > seried of pofiles".
    > 
    > If there's agreement on that concept about where
    > URNs are allowed and disallowed, then I just need
    > to settle on wording.
    > 
    > Does anyone disagree with what's formulated above?
    > 
    > If not, does this wording work (trying to use "must" or "may"
    > according to requests)
    > 
    > [suggested]:
    > 
    > URN-based XML namespaces may be used by existing TCs
    > for specifications currently under development and
    > for future deliverables belong to a family of
    > closely related specifications where architectural
    > considerations require use of URNs.  URN-based
    > XML namespaces must not be used otherwise because
    > they lack a standard, ubiquitous resolution method
    > using DNS[+HTTP].
    > 
    > - Robin
    > 
    > [1] version .01 merged-3x-TNG text was:
    > 
    > URN-based XML namespaces are also allowed for current
    > specification development efforts, but are not
    > recommended [ /* | are disallowed */ !!] otherwise,
    > as they lack a standard, ubiquitous resolution method
    > using DNS[+HTTP]
    > 
    > 
    > Robin Cover
    > OASIS, Director of Information Services
    > Editor, Cover Pages and XML Daily Newslink
    > Email: robin@oasis-open.org
    > Staff bio: http://www.oasis-open.org/who/staff.php#cover
    > Cover Pages: http://xml.coverpages.org/
    > Newsletter: http://xml.coverpages.org/newsletterArchive.html
    > Tel: +1 972-296-1783
    > 
    > 
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
    
    


  • 6.  RE: [tab] agreement on URN-based namespaces?

    Posted 10-12-2010 17:06
    Deprecated in my mind means 1) existing TCs can use the feature IFF they are already using it 2) unless a new tc is formed that is taking over the work of a tc that did use urns, new TCs must not use urns.
    
    Martin.
    
    > -----Original Message-----
    > From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
    > Sent: 12 October 2010 16:31
    > To: Robin Cover
    > Cc: OASIS TAB
    > Subject: Re: [tab] agreement on URN-based namespaces?
    > 
    > +1
    > 
    > Mary
    > 
    > 
    > 
    > 
    > On Oct 12, 2010, at 9:19 AM, Robin Cover wrote:
    > 
    > > The version .01 draft of merged-3x-TNG [now OASIS
    > > Naming Directives] flagged the rule about URNs
    > > for identifying XML namespaces with question-mark. [1]
    > >
    > > But we did not discuss in the meeting whether it
    > > should be (in that draft) "deprecated" in the sense
    > > of "not recommended" or "disallowed" [where TAB F2F
    > > minutes said "deprecated"]
    > >
    > > I'd like to remove doubt by getting agreement now, if
    > > possible, that a reasonable compromise might be
    > > to require HTML scheme URIs for all new development
    > > efforts (e.g, in new TCs), but to allow continued
    > > of URNs by TCs that currently use URNs, in both
    > > [1] specifications under development (not-yet OS
    > > or terminal CS) and [2] new deliverables that are
    > > part of a recognized family of specifications, e.g.,
    > > in a new Profile specification what will become
    > > "published profile specification #4 in an open-ended
    > > seried of pofiles".
    > >
    > > If there's agreement on that concept about where
    > > URNs are allowed and disallowed, then I just need
    > > to settle on wording.
    > >
    > > Does anyone disagree with what's formulated above?
    > >
    > > If not, does this wording work (trying to use "must" or "may"
    > > according to requests)
    > >
    > > [suggested]:
    > >
    > > URN-based XML namespaces may be used by existing TCs
    > > for specifications currently under development and
    > > for future deliverables belong to a family of
    > > closely related specifications where architectural
    > > considerations require use of URNs.  URN-based
    > > XML namespaces must not be used otherwise because
    > > they lack a standard, ubiquitous resolution method
    > > using DNS[+HTTP].
    > >
    > > - Robin
    > >
    > > [1] version .01 merged-3x-TNG text was:
    > >
    > > URN-based XML namespaces are also allowed for current
    > > specification development efforts, but are not
    > > recommended [ /* | are disallowed */ !!] otherwise,
    > > as they lack a standard, ubiquitous resolution method
    > > using DNS[+HTTP]
    > >
    > >
    > > Robin Cover
    > > OASIS, Director of Information Services
    > > Editor, Cover Pages and XML Daily Newslink
    > > Email: robin@oasis-open.org
    > > Staff bio: http://www.oasis-open.org/who/staff.php#cover
    > > Cover Pages: http://xml.coverpages.org/
    > > Newsletter: http://xml.coverpages.org/newsletterArchive.html
    > > Tel: +1 972-296-1783
    > >
    > >
    > > ---------------------------------------------------------------------
    > > To unsubscribe from this mail list, you must leave the OASIS TC that
    > > generates this mail.  Follow this link to all your TCs in OASIS at:
    > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    > 
    > 
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    > 
    


  • 7.  RE: [tab] agreement on URN-based namespaces?

    Posted 10-12-2010 17:36
    OK, thanks.  I'll try to incorporate your language to update
    and account for any maintenance activity in new TCs as
    well (disallowed for all others).  -rcc
    
    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio: http://www.oasis-open.org/who/staff.php#cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter: http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783
    
    
    On Tue, 12 Oct 2010, Martin Chapman wrote:
    
    > Deprecated in my mind means 1) existing TCs can use the feature IFF they are already using it 2) unless a new tc is formed that is taking over the work of a tc that did use urns, new TCs must not use urns.
    >
    > Martin.
    >
    >> -----Original Message-----
    >> From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
    >> Sent: 12 October 2010 16:31
    >> To: Robin Cover
    >> Cc: OASIS TAB
    >> Subject: Re: [tab] agreement on URN-based namespaces?
    >>
    >> +1
    >>
    >> Mary
    >>
    >>
    >>
    >>
    >> On Oct 12, 2010, at 9:19 AM, Robin Cover wrote:
    >>
    >>> The version .01 draft of merged-3x-TNG [now OASIS
    >>> Naming Directives] flagged the rule about URNs
    >>> for identifying XML namespaces with question-mark. [1]
    >>>
    >>> But we did not discuss in the meeting whether it
    >>> should be (in that draft) "deprecated" in the sense
    >>> of "not recommended" or "disallowed" [where TAB F2F
    >>> minutes said "deprecated"]
    >>>
    >>> I'd like to remove doubt by getting agreement now, if
    >>> possible, that a reasonable compromise might be
    >>> to require HTML scheme URIs for all new development
    >>> efforts (e.g, in new TCs), but to allow continued
    >>> of URNs by TCs that currently use URNs, in both
    >>> [1] specifications under development (not-yet OS
    >>> or terminal CS) and [2] new deliverables that are
    >>> part of a recognized family of specifications, e.g.,
    >>> in a new Profile specification what will become
    >>> "published profile specification #4 in an open-ended
    >>> seried of pofiles".
    >>>
    >>> If there's agreement on that concept about where
    >>> URNs are allowed and disallowed, then I just need
    >>> to settle on wording.
    >>>
    >>> Does anyone disagree with what's formulated above?
    >>>
    >>> If not, does this wording work (trying to use "must" or "may"
    >>> according to requests)
    >>>
    >>> [suggested]:
    >>>
    >>> URN-based XML namespaces may be used by existing TCs
    >>> for specifications currently under development and
    >>> for future deliverables belong to a family of
    >>> closely related specifications where architectural
    >>> considerations require use of URNs.  URN-based
    >>> XML namespaces must not be used otherwise because
    >>> they lack a standard, ubiquitous resolution method
    >>> using DNS[+HTTP].
    >>>
    >>> - Robin
    >>>
    >>> [1] version .01 merged-3x-TNG text was:
    >>>
    >>> URN-based XML namespaces are also allowed for current
    >>> specification development efforts, but are not
    >>> recommended [ /* | are disallowed */ !!] otherwise,
    >>> as they lack a standard, ubiquitous resolution method
    >>> using DNS[+HTTP]
    >>>
    >>>
    >>> Robin Cover
    >>> OASIS, Director of Information Services
    >>> Editor, Cover Pages and XML Daily Newslink
    >>> Email: robin@oasis-open.org
    >>> Staff bio: http://www.oasis-open.org/who/staff.php#cover
    >>> Cover Pages: http://xml.coverpages.org/
    >>> Newsletter: http://xml.coverpages.org/newsletterArchive.html
    >>> Tel: +1 972-296-1783
    >>>
    >>>
    >>> ---------------------------------------------------------------------
    >>> To unsubscribe from this mail list, you must leave the OASIS TC that
    >>> generates this mail.  Follow this link to all your TCs in OASIS at:
    >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    >>
    >>
    >> ---------------------------------------------------------------------
    >> To unsubscribe from this mail list, you must leave the OASIS TC that
    >> generates this mail.  Follow this link to all your TCs in OASIS at:
    >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    >>
    >