오래간만에 페이지의 문법 검사(markup validation check)를 하다가 tip으로 semantic data extractor(시맨틱/의미적 데이터 추출기?)라는 것을 알게 되었다. 아주 오래 전에 만들어진 것인데 왜 아직까지 몰랐을까 생각이 들었다. HTML 페이지의 주소를 입력하면 페이지의 각종 메타 데이터(제목, 저자, 요약, 연락처, 저작권, 언어, HTML Profile 등), 관계된 자원(도움말, 다음/이전 문서 등 관계된 다른 페이지, 다른 언어 페이지, RSS 피드용 페이지, 북마크가 가능한 링크 등), 정의된 용어들, 인용된 부분, 그리고 페이지의 논리적 구조 등을 보여준다. 여기에서 많은 데이터들이 제대로 추출이 된다는 것은 그만큼 페이지가 의미적으로 잘 만들어졌다는 뜻이고, 그것은 곧 검색 엔진에 제대로 노출된 확률이 크고, 기계적인 처리가 용이하다는 뜻이며, 나아가 의미적인 요소에 크게 의존하는 장애인용 보조 기술을 써서도 페이지를 잘 볼 수 있다고 해도 될 것 같다.
웹 접근성 쪽 관계자들과 가끔 만나 이야기를 하다 보면, 의외로 접근성 기술 지침에 나온 문자 그대로의 내용에 매달린 나머지, 진짜 중요한 의미 위주의 코딩(semantic markup)에 대해서 별 생각이 없는 경우를 많이 보아왔다. 그러나 장애인의 접근성과 향후 웹의 내용이 제대로 된 데이터가 되어 기계적인 처리가 원활하게 되는 것은 거의 동격이라고 해도 될 만큼 밀접한 관련이 있다. 현재에 W3C의 semantic data extractor 말고도 문서의 의미와 논리적인 구조가 제대로 작성되었는지 확인할 수 있는 방법은 몇 가지가 더 있다. 예를 들면, 오페라와 모질라, 아마야 브라우저에서는 link rel을 분석해서 표시해주거나 아예 문서의 구조적인 요소(element)들만 따로 추출해서 보여주는 기능이 있고, 파이어폭스용 확장 중에 웹 개발자용 도구모음(web developer toolbar)이나, 익스플로러용으로 나온 웹 접근성 도구모음(web accessibility toolbar)에서도 문서의 구조적인 정보를 정리해서 보여주는 기능이 있다. 하지만 semantic data extractor가 보여주는 내용은 이들과는 달리 몇 가지 범주로 나누어 상당히 많은 정보를 보여주는 것 같다. 이런 툴(tool)들이 많이 퍼졌으면 좋겠다.
웹 접근성 쪽 관계자들과 가끔 만나 이야기를 하다 보면, 의외로 접근성 기술 지침에 나온 문자 그대로의 내용에 매달린 나머지, 진짜 중요한 의미 위주의 코딩(semantic markup)에 대해서 별 생각이 없는 경우를 많이 보아왔다. 그러나 장애인의 접근성과 향후 웹의 내용이 제대로 된 데이터가 되어 기계적인 처리가 원활하게 되는 것은 거의 동격이라고 해도 될 만큼 밀접한 관련이 있다. 현재에 W3C의 semantic data extractor 말고도 문서의 의미와 논리적인 구조가 제대로 작성되었는지 확인할 수 있는 방법은 몇 가지가 더 있다. 예를 들면, 오페라와 모질라, 아마야 브라우저에서는 link rel을 분석해서 표시해주거나 아예 문서의 구조적인 요소(element)들만 따로 추출해서 보여주는 기능이 있고, 파이어폭스용 확장 중에 웹 개발자용 도구모음(web developer toolbar)이나, 익스플로러용으로 나온 웹 접근성 도구모음(web accessibility toolbar)에서도 문서의 구조적인 정보를 정리해서 보여주는 기능이 있다. 하지만 semantic data extractor가 보여주는 내용은 이들과는 달리 몇 가지 범주로 나누어 상당히 많은 정보를 보여주는 것 같다. 이런 툴(tool)들이 많이 퍼졌으면 좋겠다.
