Nikola asked me to reply to his message as otherwise it may not get
posted to RegRep TC list as his email at work does not work with regrep tc.
I too support moving forward with the current specs already submitted to
OASIS.
Thank you.
On 08/29/2011 12:38 PM, wrote:
> ---- Farrukh Najmi<> wrote:
>> Team,
>>
>> I have also looked into the broken fragments problems such as this below:
>>
>> Lines: 4146, 4424, 5380, 5401
>> http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-overview-v4.0-csprd01.html
>> *Status*: 200 OK
>>
>> Some of the links to this resource point to broken URI fragments
>> (such as index.html#fragment).
>>
>> Broken fragments:
>>
>> * http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-overview-v4.0-csprd01.html/#1.6.1.Namespaces%20Defined%7Coutline/
>> (lines 5380, 5401)
>> * http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/regrep-core-overview-v4.0-csprd01.html/#__RefHeading__32215_42233153211111111111111111/
>> (line 4424)
>>
>>
>> It turns out that these hyperlinks resolve just fine in Open Office
>> source but do not in HTML converted output. The problem is not in our
>> spec source but in the HTML conversion. Again these hyperlink between
>> sections of the same document are really just a convenience and are not
>> essential at all. We wish to keep them because they work in Open Office
>> source and we do not feel it requires any rework on our part since the
>> problem is in the conversion.
>>
>> BTW, we are hoping to have CS01 posted today and when our ballot closes
>> tomorrow I will submit the request for the Candidate OASIS Standard
>> Ballot Request
>> <http://www.oasis-open.org/resources/tc-admin-requests/candidate-oasis-standard-ballot-request>
>> so things keep moving along without delay.
>>
> +1 on moving forward and not delaying.
>
>> Thank you for your help and support.
>>
>> On 08/23/2011 05:00 PM, Farrukh Najmi wrote:
>>> Team,
>>>
>>> I have created an issue to track this at:
>>>
>>> http://jira.wx.ll.mit.edu/browse/REGREPTC-187
>>>
>>> In an earlier message, I have explained that there is only one
>>> unresolvable link with multiple instances (one for each canonical
>>> query). The hyperlink is not significant to the spec at all. Having
>>> discussed this with Chet here are some key points:
>>>
>>> * Current OASIS policy does not allow OASIS staff to simply remove
>>> the hyperlink, so this is not an option. Chet is compiling a
>>> list of minor fixes that will be allowed in future and this will
>>> be added to that list
>>> * Current OASIS policy does not allow OASIS staff to provide a
>>> server side redirect to redirect the broken link to the correct
>>> one, so this is not an option either.
>>> * Chet has said that it is up to us whether we fix this minor
>>> issue now or simply leave it in. Fixing it now would mean doing
>>> another CSD03, then PRD02 and another public review (minimum 2
>>> month delay)
>>> * I feel strongly that this sort of minor issue should not cost
>>> the TC and OASIS Staff huge rework effort and a 2 month delay.
>>> It is better to fix it if we have to address a more substantial
>>> issue or in a future version of the spec
>>> * I have asked Chet to go ahead and publish the CS01 with this
>>> issue un-addressed so we can move forward to Candidate OASIS
>>> Standard and then eventually public review prior to OASIS
>>> Standard ballot
>>>
>>> I am assuming that no one on the TC will object to this plan. If you
>>> do object then please share your thoughts. If so, you also have the
>>> opportunity until Thursday afternoon to change your vote on the ballot
>>> to publish Candidate OASIS Standard 01.
>>>
>>> Lastly, I wanted to express our collective appreciation for the good
>>> work that Chet has been doing since becoming the OASIS Staff to
>>> shepherd our TC.
>>> Despite a demanding workload he has been helping us every step of the
>>> way.
>>>
>>> On 08/22/2011 03:05 PM, Farrukh Najmi wrote:
>>>> Hi Chet,
>>>>
>>>> We had used the following online link checker before submitting the
>>>> specs:
>>>>
>>>> http://validator.w3.org/checklink?uri=http%3A%2F%2Fdocs.oasis-open.org%2Fregrep%2Fregrep-core%2Fv4.0%2Fcsd02%2Fregrep-core-rs-v4.0-csd02.html&hide_type=all&depth=&check=Check
>>>>
>>>> *ACTION: TC Members please review results from links below to double
>>>> check that there are no other errors:
>>>> *
>>>>
>>>> * Overview:
>>>> http://validator.w3.org/checklink?uri=http%3A%2F%2Fdocs.oasis-open.org%2Fregrep%2Fregrep-core%2Fv4.0%2Fcsprd01%2Fregrep-core-overview-v4.0-csprd01.html&hide_type=all&depth=&check=Check
>>>> * ebRIM:
>>>> http://validator.w3.org/checklink?uri=http%3A%2F%2Fdocs.oasis-open.org%2Fregrep%2Fregrep-core%2Fv4.0%2Fcsprd01%2Fregrep-core-rim-v4.0-csprd01.html&hide_type=all&depth=&check=Check
>>>> * ebRS:
>>>> http://validator.w3.org/checklink?uri=http%3A%2F%2Fdocs.oasis-open.org%2Fregrep%2Fregrep-core%2Fv4.0%2Fcsd02%2Fregrep-core-rs-v4.0-csd02.html&hide_type=all&depth=&check=Check
>>>>
>>>>
>>>> Most of the errors in the result of the link checker are false
>>>> positives due to links that from URLs that were used in examples and
>>>> were never meant to be anything more than examples. These all start
>>>> with "http://acme.com".
>>>>
>>>>
>>>> Looking at the latest results from CSD02 I find only one link that
>>>> has several instances that is an actual mistake:
>>>>
>>>> Lines: 7489, 7570, 7785, 8019, 8056, 8191, 8326, 8438, 8673, 8752,
>>>> 8828, 8933, 9007, 9082, 9174, 9506
>>>> http://docs.oasis-open.org/regrep/v4.0/canonical/SubmitObjectsRequest_Queries.xml
>>>>
>>>> The actual links for CSPRD01 should be:
>>>>
>>>> http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/xml/minDB/SubmitObjectsRequest_Queries.xml
>>>>
>>>> The problem is that OASIS does not publish a version independent link
>>>> to this file at:
>>>>
>>>> http://docs.oasis-open.org/regrep/regrep-core/v4.0/xml/minDB/SubmitObjectsRequest_Queries.xml
>>>>
>>>> The resolution for this one error is to simply remove the hyperlink
>>>> as it is not actually needed and in fact creates issues because OASIS
>>>> does not publish a version independent link to the file or its parent
>>>> directory.
>>>>
>>>> Another possible resolution is to create a redirect from
>>>> http://docs.oasis-open.org/regrep/v4.0/canonical/SubmitObjectsRequest_Queries.xml
>>>>
>>>> to
>>>> http://docs.oasis-open.org/regrep/regrep-core/v4.0/csprd01/xml/minDB/SubmitObjectsRequest_Queries.xml
>>>> at the OASIS web site.
>>>>
>>>> Is either of these (removing hyperlinks in a few places or creating a
>>>> redirect) something we can do without having to submit another
>>>> CSD/PRD and creating a lot of work for editors as well as OASIS staff?
>>>>
>>>> Please let us know how you think its bets to proceed and we will work
>>>> with you to get beyond this.
>>>>
>>>> Lastly, I lets discuss what we can change in the Standards Approval
>>>> process so minor mistakes like this could be caught earlier before
>>>> going to public review.
>>>>
>>>> Thank you.
>>>>
>>>> On 08/22/2011 01:36 PM, Chet Ensign wrote:
>>>>> Hi Farrukh, hi Kathryn,
>>>>>
>>>>> In preparing the Committee Specification files for the 3 parts of
>>>>> Regrep V4.0, we found numerous broken links. 44 were found in Part 2
>>>>> and there are some in the other files as well.
>>>>>
>>>>> Some are broken internal links to different sections of the document.
>>>>>
>>>>> In Part 2 ebRS, there are many links in function documentation that do
>>>>> not work. See for example, 2.6 Canonical Query:
>>>>> ClassificationSchemeSelector where the link behind "canonical query
>>>>> ClassificationSchemeSelector" doesn't work. It points to the URI
>>>>> http://docs.oasis-open.org/regrep/v4.0/canonical/SubmitObjectsRequest_Queries.xml
>>>>> however neither the subdirectory /canonical/ nor the XML exists. (You
>>>>> can find these in the previous CSD and see the problem there.)
>>>>>
>>>>> Do you have a link checker that you can use to identify broken links?
>>>>>
>>>>> Do you want to pull this back from promotion to CS and fix these now?
>>>>>
>>>>> Please let me know how you want to proceed.
>>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
