[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Version identifier for XRD spec
On Mon, 24 Nov 2008, Drummond Reed wrote:
> I'm thinking that "/ns/" in the template corresponds to "/xscoor/" in the
> instance example.
[...]
> I'm thinking what the template meant we could use was:
>
> http://docs.oasis-open.org/xri/xrd/2008/12
No. Please see the text here:
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#uri-NS-root
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#NS-pathElement
See the documentation for the new (Naming Guidelines -08)
pattern with the explicit /ns/ element, and example:
http://docs.oasis-open.org/codelist/ns/genericode/1.0/
Per:
http://lists.oasis-open.org/archives/xri/200811/msg00125.html
- Robin
-------------------------------
> Eran, our messages crossed in the mail. +1, but see inline for one
> clarification.
>
>> -----Original Message-----
>> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
>> Sent: Monday, November 24, 2008 3:49 PM
>> To: Drummond Reed; Robin Cover; Gabe Wachob
>> Cc: Nat Sakimura; mary.mcrae@oasis-open.org; OASIS XRI TC;
>> sakimura@spmd.nri.co.jp
>> Subject: Re: [xri] RE: Version identifier for XRD spec
>>
>> The examples from Robinšs link directly point to:
>>
>> http://docs.oasis-open.org/ws-tx/wscoor/2006/03
>>
>> As a valid XML namespace. Perhaps missing the /ns/ component from the
>> current template:
>>
>> http://docs.oasis-open.org/<ShortName>/ns/<Versioned-NS-String>
>
> I'm thinking that "/ns/" in the template corresponds to "/xscoor/" in the
> instance example.
>
>> But either way, dates are definitely permitted within OASIS namespaces. I
>> therefore suggest this is a the resolution of this thread:
>>
>> 1. Spec name is XRD 1.0
>> 2. Drop version attribute
>> 3. XML namespace: http://docs.oasis-open.org/xri/ns/xrd/2008/12 (if still
>> allowed, otherwise) http://docs.oasis-open.org/xri/ns/xrd-200812
>
> I'm thinking what the template meant we could use was:
>
> http://docs.oasis-open.org/xri/xrd/2008/12
>
> But I'm sure Mary McRae can help us finalize the format - the key concept is
> that we can use a date-based version identifier.
>
>> The actual date will be the month of the first draft.
>
> +1
>
> =Drummond
>
>> On 11/24/08 3:36 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:
>>
>>> Robin, thanks for the guidance and links. I've suggested to Mary (who I
>>> realize is gone this week) that we have a short telecon after she's back
>>> with all the editors who will be working on the next round of specs from
>> the
>>> XRI TC, as several are new to OASIS specs and editing requirements.
>>>
>>> =Drummond
>>>
>>>> -----Original Message-----
>>>> From: Robin Cover [mailto:robin@oasis-open.org]
>>>> Sent: Monday, November 24, 2008 10:40 AM
>>>> To: Gabe Wachob
>>>> Cc: Eran Hammer-Lahav; Drummond Reed; Nat Sakimura; mary.mcrae@oasis-
>>>> open.org; OASIS XRI TC; sakimura@spmd.nri.co.jp
>>>> Subject: Re: [xri] RE: Version identifier for XRD spec
>>>>
>>>> Just a recommendation:
>>>>
>>>> I don't think it would be a mistake to keep one eye on details of the
>>>> OASIS Naming Guidelines as the TC deliberates about such things
>>>> as construction of a spec title, use of version/revision identifiers,
>>>> namespace URI considerations, (required) use of both instance
>>>> (version-specific) and generic (version-agnostic) URIs for schemas
>>>> as well as prose specs, etc. And also, on the TC Process document.
>>>>
>>>> Examples:
>>>>
>>>> http://docs.oasis-
>>>>
>> open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#NamespaceD
>>>> esign
>>>> (includes 'change policies for XML namespaces')
>>>>
>>>> http://docs.oasis-
>>>> open.org/specGuidelines/namingGuidelines/metadata04.html#title
>>>>
>>>> http://docs.oasis-
>>>> open.org/specGuidelines/namingGuidelines/metadata04.html#version
>>>>
>>>> http://docs.oasis-
>>>> open.org/specGuidelines/namingGuidelines/metadata04.html#specURIs
>>>>
>>>> http://docs.oasis-
>>>>
>> open.org/specGuidelines/namingGuidelines/metadata04.html#declaredNamespace
>>>> (namespace document, if you use HTTP scheme NS URI)
>>>>
>>>> http://docs.oasis-
>>>>
>> open.org/specGuidelines/namingGuidelines/metadata04.html#latestVersionURIs
>>>> -schemas
>>>> "Latest Version" URIs for Schemas, WSDLs, RDDLs, and Other
>> Specification
>>>> Components
>>>>
>>>> TC Prosess 2.18
>>>> http://www.oasis-open.org/committees/process-2008-06-19.php#specQuality
>>>>
>>>> A specification may be composed of any number of files of
>>>> different types, though any such multi-part specification
>>>> must have a single specification name and version number.
>>>> Irrespective of the number and status of the constituent
>>>> parts, the specification as a whole must be approved by a
>>>> single TC ballot. Any change made to a specification
>>>> requires a new version or revision number...
>>>>
>>>> [NB Mary is out of the office for this week]
>>>>
>>>> -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 Mon, 24 Nov 2008, Gabe Wachob wrote:
>>>>
>>>>> I'd be happy with calling it XRD 1.0 if we use a dated namespace so
>>>> people
>>>>> don't have *any* confusion about the fact that this is the "most
>>>> current"
>>>>> spec relative to XRI...
>>>>>
>>>>> Its also a sort of emerging best practice for namespaces from the W3C,
>>>>> afaict.
>>>>>
>>>>> And of course, I'm happy with an HTTP namespace ;)
>>>>>
>>>>> I'm happy with dropping version - that was there mostly to allow
>>>> backwards
>>>>> compatibility - the idea being that a future interpreter could pick up
>>>> an
>>>>> older XML document and understand what it was looking at. This would
>>>> leave us
>>>>> as spec writers free to add new elements in a "backwards compatible"
>>>> manner,
>>>>> while allowing the documen to give hints to "up to date"
>> implementations
>>>> what
>>>>> level the spec was at. The idea was that you would be able to rev the
>>>> schema
>>>>> much slower than the spec interpreting it.
>>>>>
>>>>> -Gabe
>>>>>
>>>>> On Nov 24, 2008, at 9:11 AM, Eran Hammer-Lahav wrote:
>>>>>
>>>>>> My vote is to:
>>>>>>
>>>>>> Name the spec XRD 1.0
>>>>>> Drop the ?version? attribute
>>>>>> Drop the proposal to have multiple ?profiles? (i.e. XRDS-Simple)
>>>>>> Use an HTTP namespace under the OASIS domain with version 1.0. If
>>>> people
>>>>>> find this confusing, I would be ok with a dated namespace. As a last
>>>>>> resort, I would support using a version 3.0 namespace with an
>>>> explanation
>>>>>> why the spec itself is version 1.0.
>>>>>>
>>>>>> Here is why:
>>>>>>
>>>>>>
>>>>>> I think the real question here is what to do with the ?version?
>>>> attribute.
>>>>>> In many ways, it is very similar to the ?profile? attribute proposed
>>>>>> earlier to support the XRDS-Simple use case. I am ?1 on both and here
>>>> is
>>>>>> why. My understanding of the ?version? attribute is that it refers
>> only
>>>> to
>>>>>> the resolver workflow, not to the schema which is independently
>>>> versioned
>>>>>> via an XML namespace.
>>>>>>
>>>>>> I cannot think of use cases where the schema does not change at all,
>>>> but
>>>>>> the meaning of the document does. The most likely scenario to happen
>> is
>>>>>> adding elements via XML namespace import, and in that case, the
>>>> resolver
>>>>>> will need to take those new additions into account (as they may
>> change
>>>> the
>>>>>> meaning of the document). I believe that the schema itself is more
>> than
>>>>>> just a format but also tightly linked to its meaning. If we want to
>>>> change
>>>>>> the meaning but not the schema, we should still change the XML
>>>> namespace.
>>>>>> Either way, existing parsers will need to change so why does it
>> matter
>>>> what
>>>>>> breaks them (different version of different namespace).
>>>>>>
>>>>>> In addition, I have changed my views on the ?profile? attribute. I
>>>> think at
>>>>>> this point the only element which might be considered ?advance? is
>>>> <Ref>
>>>>>> and it is an important requirement for any delegation of metadata.
>> The
>>>> only
>>>>>> other issue raised by developers was the ?priority? attribute but
>>>> again, it
>>>>>> is too important to remove.
>>>>>>
>>>>>> If we remove these two attributes, we are left with a single unified
>>>> schema
>>>>>> which will get a new namespace. Since this new namespace will be an
>>>> HTTP
>>>>>> URI, I do not think it matters if it is version 1.0 or dated. It will
>>>> be
>>>>>> sufficiently different form the XRI namespace (which more people
>> didn?t
>>>>>> understand) and from the version attribute value. Because of that I
>>>> lean
>>>>>> more towards a version 1.0 in the namespace than a date, but will
>> take
>>>> a
>>>>>> date over version 3.0.
>>>>>>
>>>>>> The spec itself should be XRD 1.0 either way, not matter what
>> namespace
>>>> we
>>>>>> end up using (and assuming we are dropping the ?version? attribute).
>> It
>>>> is
>>>>>> better to version it 1.0 and put a comment why the namespace has 3.0
>> in
>>>> it,
>>>>>> than make everything 3.0...
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>
>>>>>> On 11/23/08 11:18 PM, "Drummond Reed" <drummond.reed@cordance.net>
>>>> wrote:
>>>>>>
>>>>>> Nat, RE your [Q1], I don't think OASIS mandates how schemas are
>>>> versioned.
>>>>>> That's up to individual TCs (I'm trusting Mary or Robin will correct
>> me
>>>> if
>>>>>> I'm wrong.]
>>>>>>
>>>>>> RE your [Q2], I think that it is also up to us when we make a version
>>>>>> change. Changing the schema would seem to be one of the conditions
>>>> under
>>>>>> which we would definitely make a version change, but it does seem
>> like
>>>>>> other
>>>>>> spec changes could also trigger a version change (for example, as you
>>>>>> mentioned, verification rules).
>>>>>>
>>>>>> Suggestion: since much of this seems to hinge around whether the XRD
>>>> schema
>>>>>> retains a version attribute, why don't selector see if we can decide
>>>> that
>>>>>> first.
>>>>>>
>>>>>> 1) Who has strong feelings one way or another about whether the XRD
>>>> schema
>>>>>> should have a version attribute?
>>>>>>
>>>>>> 2) If so, should the use of the version attribute be required?
>>>>>>
>>>>>> 3) If there is a version attribute, who has strong feeling about it
>>>> being
>>>>>> numeric (as it currently is in XRI Resolution 2.0)? Or a date value?
>>>>>>
>>>>>> =Drummond
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
>>>>>>> Sent: Sunday, November 23, 2008 6:11 AM
>>>>>>> To: mary.mcrae@oasis-open.org; OASIS XRI TC
>>>>>>> Cc: Gabe Wachob; Drummond Reed; Eran Hammer-Lahav;
>>>> sakimura@spmd.nri.co.jp
>>>>>>> Subject: Re: [xri] RE: Version identifier for XRD spec
>>>>>>>
>>>>>>> So, to sum it up, there has been several information
>> points/resonings
>>>>>>> available around versions:
>>>>>>>
>>>>>>> (1) Since it is a new spec, it shoud start from 1.0. Otherwise
>> people
>>>>>>> start looking for 1.0.
>>>>>>> (2) Since there is <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)">
>> in
>>>>>>> XRDS right now.
>>>>>>> using 1.0 may confuse people. Perhaps we should use 3.0.
>>>>>>> (3) However, if version attribute goes away, this is of less
>> concern.
>>>>>>> Version of the schema can be represented in xmlns, and it will
>>>> be
>>>>>>> a new
>>>>>>> http based version string possibly starting from 1.0 or dates
>> in
>>>>>>> W3C style.
>>>>>>> Besides, schema version and spec version can be separate.
>>>>>>> (4) OASIS rule mandates the specs to be versioned numerically.
>>>>>>>
>>>>>>> I have a couple of questions at this point.
>>>>>>>
>>>>>>> [Q1] Is the OASIS versioning rule on the spec also applicable to the
>>>>>>> schema contained in the spec?
>>>>>>> [Q2] Is there a case where we want to preserve "version" attribute
>>>>>>> separate from the schema version?
>>>>>>> e.g., when verification rule is changed etc., should it always
>>>>>>> require the schema version change as well?
>>>>>>>
>>>>>>> If the answer to [Q1] is no, then we can use date based name space
>> in
>>>>>>> <XRD ... > and cause
>>>>>>> less confusion even if we adopt XRD 1.0. If the answer is "Yes",
>> then
>>>> I
>>>>>>> would be more inclined to "3.0".
>>>>>>>
>>>>>>> For [Q2], I am yet to come up with a case. If any of you could think
>>>> of
>>>>>>> it, please let me know.
>>>>>>>
>>>>>>> =nat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gabe Wachob wrote:
>>>>>>>> Lets call it XRD 7!
>>>>>>>>
>>>>>>>> -Gabe
>>>>>>>>
>>>>>>>> On Fri, Nov 21, 2008 at 11:11 PM, Drummond Reed
>>>>>>>> <drummond.reed@cordance.net <mailto:drummond.reed@cordance.net>>
>>>> wrote:
>>>>>>>>
>>>>>>>> Mary McRae, our TC admin, clarified that OASIS specs must use a
>>>>>>>> numeric
>>>>>>>> version identifier (see thread below).
>>>>>>>>
>>>>>>>> So, mates, now we really do have to decide between "XRD 1.0"
>> and
>>>>>>>> "XRD 3.0".
>>>>>>>>
>>>>>>>> A suggestion: if, as we discussed on Thursday's call, the new
>>>> XRD
>>>>>>>> spec will
>>>>>>>> no longer have a "ver" attribute on the XRD element, then the
>>>>>>>> issue of the
>>>>>>>> previous version attribute value being "2.0" (as specified in
>>>> XRI
>>>>>>>> Resolution
>>>>>>>> 2.0) will go away. In that case I think it makes sense to call
>>>> the
>>>>>>>> spec "XRD
>>>>>>>> 1.0" because as Eran pointed out, there's never been a spec
>> from
>>>>>>>> the TC
>>>>>>>> called "XRD" before.
>>>>>>>>
>>>>>>>> OTOH, if the decision is that the ver attribute on XRD element
>>>>>>>> should stay,
>>>>>>>> then I think it makes sense to call the spec "XRD 3.0" because
>>>> it
>>>>>>>> really is
>>>>>>>> the next version of XRD. We can always put a note in the
>>>>>>>> frontmatter telling
>>>>>>>> readers not to look for an "XRD 2.0" or "XRD 1.0" spec, but
>>>>>>>> instead to look
>>>>>>>> at "XRI Resolution 2.0" and "XRI 1.0" for the predecessor
>>>>>>>> specifications.
>>>>>>>>
>>>>>>>> All things being equal (which they never are ;-), I favor
>>>> planning
>>>>>>> for
>>>>>>>> future growth and extensibility, which means I favor keeping
>> the
>>>>>>>> versioning
>>>>>>>> attribute, which tips me ever so slightly towards "XRD 3.0".
>>>> (Which
>>>>>>> is
>>>>>>>> ironic because I prefer the spec name "XRD 1.0" because it's a
>>>> new
>>>>>>>> spec.)
>>>>>>>>
>>>>>>>> I don't think the issue is worth taking a bunch of list
>>>> bandwidth
>>>>>>>> to figure
>>>>>>>> out, so I'd recommend that:
>>>>>>>>
>>>>>>>> a) Anyone else on the list with strong feelings either way,
>>>> please
>>>>>>>> post your
>>>>>>>> thoughts by Monday.
>>>>>>>>
>>>>>>>> b) Eran and Nat as the editors discuss it and make a
>>>> recommendation.
>>>>>>>>
>>>>>>>> =Drummond
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mary McRae [mailto:marypmcrae@gmail.com
>>>>>>>> <mailto:marypmcrae@gmail.com>] On Behalf Of Mary McRae
>>>>>>>>> Sent: Friday, November 21, 2008 5:23 AM
>>>>>>>>> To: 'Drummond Reed'
>>>>>>>>> Subject: RE: Version identifier for XRD spec
>>>>>>>>>
>>>>>>>>> You found the right (and required) answer ;-)
>>>>>>>>>
>>>>>>>>> Mary
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Drummond Reed [mailto:drummond.reed@cordance.net
>>>>>>>> <mailto:drummond.reed@cordance.net>]
>>>>>>>>>> Sent: Friday, November 21, 2008 1:22 AM
>>>>>>>>>> To: 'OASIS XRI TC'; mary.mcrae@oasis-open.org
>>>>>>>> <mailto:mary.mcrae@oasis-open.org>
>>>>>>>>>> Subject: Version identifier for XRD spec
>>>>>>>>>>
>>>>>>>>>> Mary,
>>>>>>>>>>
>>>>>>>>>> From today's XRI TC call I had an action item to send you
>>>> and
>>>>>>>> the TC
>>>>>>>>>> list an
>>>>>>>>>> email asking about OASIS spec naming guidelines. Based on
>>>> the
>>>>>>>> helpful
>>>>>>>>>> info
>>>>>>>>>> about spec packaging you gave us two weeks ago, the TC is
>>>>>>>> currently
>>>>>>>>>> planning
>>>>>>>>>> two new specs, both of which we intend to take to OASIS
>>>>>>>> Standard level:
>>>>>>>>>> XRI
>>>>>>>>>> 3.0 and XRD xxx (xxx = version identifier TBD).
>>>>>>>>>>
>>>>>>>>>> XRI 3.0 will consist of four parts (1: Syntax, 2:
>>>> Resolution,
>>>>>>>> 3: http:
>>>>>>>>>> and
>>>>>>>>>> https: Bindings, and 4: info: Binding). XRD will probably be
>>>> a
>>>>>>>> single
>>>>>>>>>> spec,
>>>>>>>>>> though it might be two parts.
>>>>>>>>>>
>>>>>>>>>> Now, the question is about versioning on the XRD spec. This
>>>> is
>>>>>>>> a new
>>>>>>>>>> spec
>>>>>>>>>> that represents splitting off a significant portion of the
>>>>>>>> content of
>>>>>>>>>> the
>>>>>>>>>> XRI Resolution 2.0 spec into a new spec that defines a
>>>> generic
>>>>>>>> metadata
>>>>>>>>>> discovery format and protocol which the new XRI 3.0 Part 2:
>>>>>>>> Resolution
>>>>>>>>>> spec
>>>>>>>>>> will then profile (as will other specs, e.g. SAML, OpenID,
>>>>>>>> OAuth, etc.
>>>>>>>>>> who
>>>>>>>>>> want to use interoperable discovery).
>>>>>>>>>>
>>>>>>>>>> Our first question is: does an OASIS spec need to use a
>>>>>>>> numeric version
>>>>>>>>>> identifier? In researching this tonight, I believe the
>>>> answer
>>>>>>>> is at:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://docs.oasis-
>>>>>>>>>> open.org/specGuidelines/namingGuidelines/metadata.html#ver
>>>>>>>>
>>>> <http://open.org/specGuidelines/namingGuidelines/metadata.html#ver>
>>>>>>>>>> sion
>>>>>>>>>>
>>>>>>>>>> ...which states:
>>>>>>>>>>
>>>>>>>>>> *******************
>>>>>>>>>> A specification Version is represented textually by a
>>>> numeric
>>>>>>>> string
>>>>>>>>>> composed of digits [0-9] and period (".") corresponding to
>>>> any
>>>>>>>> of the
>>>>>>>>>> following lexical models provided below (as examples), as
>>>> may be
>>>>>>>>>> relevant to
>>>>>>>>>> the TC's work activity and preference for major/minor
>>>> version
>>>>>>>> notation.
>>>>>>>>>> Formally, using parenthesis to indicate optionality and "#"
>>>> to
>>>>>>>>>> represent a
>>>>>>>>>> digit, the allowable pattern is: #(#).#(#)(.#(#)). Use of
>>>> any
>>>>>>>> other
>>>>>>>>>> pattern
>>>>>>>>>> for version number must be negotiated with the TC
>>>>>>> Administration.
>>>>>>>>>>
>>>>>>>>>> Examples:
>>>>>>>>>>
>>>>>>>>>> 1.0 #.#
>>>>>>>>>> 1.01 #.##
>>>>>>>>>> 1.2.1 #.#.#
>>>>>>>>>> 10.1 ##.#
>>>>>>>>>> ********************
>>>>>>>>>>
>>>>>>>>>> If so, that answers the question, and we just need to decide
>>>>>>> what
>>>>>>>>>> version
>>>>>>>>>> number to give it (in short: one rationale is to call it 1.0
>>>>>>>> because it
>>>>>>>>>> is a
>>>>>>>>>> new spec; another is to call it 3.0 because it derives from
>>>> two
>>>>>>>>>> generations
>>>>>>>>>> of XRDS before it -- but that's our issue to figure out).
>>>>>>>>>>
>>>>>>>>>> However, if we do have any flexibility, we want to at least
>>>>>>>> ask you
>>>>>>>>>> about
>>>>>>>>>> using a year/date identifier instead of a version number.
>>>>>>>>>>
>>>>>>>>>> Thanks in advance. (BTW, I'm thinking of setting up a call
>>>> in
>>>>>>>> early
>>>>>>>>>> December
>>>>>>>>>> between you and the editors of these new specs to a general
>>>>>>>> Q&A about
>>>>>>>>>> all
>>>>>>>>>> things involved with the mechanics of an OASIS spec. Sound
>>>>>>>> like a good
>>>>>>>>>> idea?)
>>>>>>>>>>
>>>>>>>>>> =Drummond
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>> -
>>>> ----
>>>>>>> -
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Gabe Wachob / gwachob@wachob.com <mailto:gwachob@wachob.com> \
>>>>>>>> http://blog.wachob.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>> -
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]