IT story

SAX 모델 용 XPath 프로세서가 있습니까?

hot-time 2020. 12. 31. 22:54
반응형

SAX 모델 용 XPath 프로세서가 있습니까?


문서의 노드를 찾기 위해 전체 DOM 문서를 다시 빌드하지 않는 XPath 평가자를 찾고 있습니다. 실제로 객체는 SAX 모델을 사용하여 많은 양의 XML 데이터 (이상적으로는 2Gb 이상)를 관리하는 것입니다. 메모리 관리에 좋으며 노드 검색 가능성을 제공합니다.

지원 해주셔서 감사합니다!

불가능하다고 말하는 모든 사람들을 위해 : 최근에 질문을 한 후 "saxpath"( http://www.saxpath.org/ ) 라는 프로젝트를 찾았 지만 구현 프로젝트를 찾을 수 없습니다.


내 현재 목록 (웹 검색 결과 및 기타 답변에서 수집)은 다음과 같습니다.

다음 단계는 XMLDog의 예를 사용하고 이러한 모든 접근 방식의 성능을 비교하는 것입니다. 그런 다음 테스트 케이스를 지원되는 XPath 표현식으로 확장해야합니다.


XPath를 사용하여 편리하게 쿼리 할 수있는 부분 DOM 트리를 추출하는 SAX 파서를 사용하여 1GB 이상의 복잡한 XML 파일을 정기적으로 구문 분석합니다. 나는 여기에 대해 블로그 : http://softwareengineeringcorner.blogspot.com/2012/01/conveniently-processing-large-xml-files.html - 근원에서 사용할 수있는 GitHub의 MIT 라이센스 -.


XPath는 SAX와 함께 작동하며 대부분의 XSLT 프로세서 (특히 Saxon 및 Apache Xalan)는 전체 DOM을 빌드하지 않고 SAX 스트림에서 XSLT 내부의 XPath 표현식 실행을 지원합니다.

다음과 같이 매우 대략적으로 수행합니다.

  1. 일치해야하는 XPath 표현식 검토
  2. SAX 이벤트를 수신하고 해당 노드가 XPath 표현식 중 하나에 필요한지 테스트합니다.
  3. XPath 표현식에 사용되지 않는 경우 SAX 이벤트를 무시합니다.
  4. 필요한 경우 버퍼링

버퍼링 방법도 매우 흥미 롭습니다. 일부는 여기저기서 DOM 조각을 생성하는 반면 다른 일부는 빠른 조회와 메모리 소비 감소를 위해 매우 최적화 된 테이블을 사용합니다.

그들이 얼마나 많은 최적화를 관리 하느냐는 그들이 찾은 XPath 쿼리의 종류에 달려 있습니다. 이미 게시 된 Saxon 문서에서 명확하게 설명 하듯이 "위로"이동 한 다음 "수평으로"(형제 별 형제) 횡단하는 쿼리는 문서 전체가 있어야하지만 대부분은 몇 개의 노드 만 보관하면됩니다. 언제든지 RAM.

Cocoon을 사용하여 매일 웹앱을 만들었을 때 XSLT 내에서 "// something"표현식을 사용할 때마다 XSLT 메모리 풋 프린트 문제가 발생했고, XPath 표현식을 재 작업해야하는 경우가 많았습니다. 더 나은 SAX 최적화를 허용합니다.


SAX는 정방향 전용이지만 XPath 쿼리는 모든 방향 ( , 고려 parent::) 으로 문서를 탐색 할 수 있습니다 . 나는 이것이 일반적으로 어떻게 가능할 지 모르겠습니다. 가장 좋은 근사치는 일종의 지연 로딩 DOM이지만, 쿼리에 따라 이점을 제공 할 수도 있고 제공하지 않을 수도 있습니다 ..ancestor::preceding::preceding-sibling:://*[. != preceding::*]


죄송합니다. 약간 늦은 답변입니다. XPath의 하위 집합에서 가능한 것 같습니다. 일반적으로 XPath가 "현재"지점에서 앞뒤로 모두 일치 할 수 있기 때문에 매우 어렵습니다. 상태 머신을 사용하여 어느 정도 문제를 해결하는 두 가지 프로젝트를 알고 있습니다 : http://spex.sourceforge.net & http://www.cs.umd.edu/projects/xsq . 자세히 살펴 보지는 않았지만 비슷한 접근 방식을 사용하는 것 같습니다.


AXS라는 새 프로젝트를 위해 플러그를 꽂을 것입니다. 그것은에서의 https://code.google.com/p/annotation-xpath-sax/ 과 생각은 그와 당신 주석 방법 (앞으로 축 전용)의 XPath 문과는 그들이 SAX 파서가 노드에있을 때 호출되는 일치합니다. 그래서 문서로

<doc>
<nodes>
  <node name="a">text of node 1</node>
  <node name="b">text of node 2</node>
  <node otherattr="I have attributes!">text of node 3</node>
</nodes>
</doc>

당신은 같은 일을 할 수 있습니다

@XPath("/nodes/node")
void onNode(String nodeText)
{
  // will be called with "text of node [123]"
}

또는

@XPathStart("//node[@name='']")
void onNode3(Attrs node3Attrs) { ... }

또는

@XPathEnd("/nodes/node[2]")
void iDontCareAboutNode3() throws SAXExpression
{
  throw new StopParsingExpression();
}

물론 라이브러리는 너무 새롭기 때문에 아직 출시하지 않았지만 MIT 라이센스가 있으므로 자유롭게 시도하고 필요에 맞는지 확인하십시오. (이전 Android 기기에서 실행할 수있는 충분한 메모리 요구 사항으로 HTML 화면 스크래핑을 수행하기 위해 작성했습니다 ...) 버그를 발견하면 googlecode 사이트에 신고하여 알려주세요!


늦은 답변으로 죄송하지만 SAX 파서에 대한 간단한 XPath 표현식 경로를 구현했습니다 . SAX의 순방향 특성으로 인해 태그, 선택적 값이있는 속성 및 색인 만 지원합니다. Handler가 ExpressionFilter를 구현할 때 주어진 식을 평가하기 위해 위임 Handler만들었습니다 . 이러한 클래스는 프로젝트에 포함되어 있지만 추출하기가 어렵지 않습니다.

More information

Examples - See classes with the HandlerHtml prefix


There are SAX/StAX based XPath implementations, but they only support a small subset of XPath expressions/axis largely due to SAX/StAX's forward only nature.. the best alternative I am aware of is extended VTD-XML, it supports full xpath, partial document loading via mem-map.. and a max document size of 256GB, but you will need 64-bit JVM to use it to its full potential


What you could do is hook an XSL transformer to a SAX input source. Your processing will be sequential and the XSL preprocessor will make an attempt to catch the input as it comes to fiddle it into whatever result you specified. You can use this to pull a path's value out of the stream. This would come in especially handy if you wanted to produce a bunch of different XPATH results in one pass.

You'll get (typically) an XML document as a result, but you could pull your expected output out of, say, a StreamResult with not too much hassle.


Have a look at the streaming mode of the Saxon-SA XSLT-processor.

http://www.saxonica.com/documentation/sourcedocs/serial.html

"The rules that determine whether a path expression can be streamed are:

  • The expression to be streamed starts with a call on the document() or doc() function.
  • The path expression introduced by the call on doc() or document must conform to a subset of XPath defined as follows:

  • any XPath expression is acceptable if it conforms to the rules for path expressions appearing in identity constraints in XML Schema. These rules allow no predicates; the first step (but only the first) can be introduced with "//"; the last step can optionally use the attribute axis; all other steps must be simple Axis Steps using the child axis.

  • In addition, Saxon allows the expression to contain a union, for example doc()/(*/ABC | /XYZ). Unions can also be expressed in abbreviated form, for example the above can be written as doc()//(ABC|XYZ).
  • The expression must either select elements only, or attributes only, or a mixture of elements and attributes.

  • Simple filters (one or more) are also supported. Each filter may apply to the last step or to the expression as a whole, and it must only use downward selection from the context node (the self, child, attribute, descendant, descendant-or-self, or namespace axes). It must not be positional (that is, it must not reference position() or last(), and must not be numeric: in fact, it must be such that Saxon can determine at compile time that it will not be numeric). Filters cannot be applied to unions or to branches of unions. Any violation of these conditions causes the expression to be evaluated without the streaming optimization.

  • These rules apply after other optimization rewrites have been applied to the expression. For example, some FLWOR expressions may be rewritten to a path expression that satisfies these rules.

  • The optimization is enabled only if explicitly requested, either by using the saxon:stream() extension function, or the saxon:read-once attribute on anXSLT xsl:copy-of instruction, or the XQuery pragma saxon:stream. It is available only if the stylesheet or query is processed using Saxon-SA."

Note: It is most likely in the commercial version this facility is available. I've used Saxon extensively earlier, and it is a nice piece of work.


Mmh I don't know if I really understand you. As far as I know, the SAX model is event oriented. That means, you do something if a certain node is encountered during the parsing. Yeah, it is better for memory but I don't see how you would like to get XPath into it. As SAX does not build a model, I don't think that this is possible.


The standard javax xpath API technically already works with streams; javax.xml.xpath.XPathExpression can be evaluated against an InputSource, which in turn can be constructed with a Reader. I don't think it constructs a DOM under the covers.


I don't think xpath works with SAX, but you might take a look at StAX which is an extended streaming XML API for Java.

http://en.wikipedia.org/wiki/StAX


Did you have tried also QuiXPath https://code.google.com/p/quixpath/ ?

ReferenceURL : https://stackoverflow.com/questions/1863250/is-there-any-xpath-processor-for-sax-model

반응형